To the second point, named parameters as implemented by Function::Parameters do provide this checking if you want it to. Named parameters was a planned feature for core signatures and hopefully it will have similar functionality.
That announced that it could be used as a second name, but provided no further guidance, so Perl 6 is still used by many thus its problems are still just as present. This proposal would be to actually consistently use Raku as the name of the language.
Well, not strictly mistaken, but severely outdated. The CPAN module did try to upgrade Perl in ancient versions, and this of course was a terrible idea.
This would be a pretty difficult change. Aside from backwards incompatibility, module names are both filesystem lookups and package stash lookups, and in most cases both of those are case sensitive, and it's entirely possible for valid programs to use two modules that only differ in case - at best I could see a warning that searches for a "did you mean?" but that sounds slow.
Memorizing everything is not required, there is reference documentation. Learning the language would familiarize you with the important syntax, as with any language, and all languages have such oddities, they just appear in different forms.
Unfortunate realities of 1) the difficulty of working on the Perl codebase combined with its unpopularity leading to few being both qualified and motivated for such a task, 2) a lack of corporate backing or visionary design purpose driving such features in the language, thus 3) being implemented almost entirely by one individual who had a long period of demotivation and sickness.
In practice (from a rough survey of CPAN code and Perl code in the wild I've looked at), people rarely use the English versions, and tend to memorize the few punctuation variables that are commonly used: $_, @_, $/, $], $$, $@, $!, $? (and note that some of these are out of familiarity with other languages) and ignore the rest unless needed for a specific problem.
Note that you can mix the languages in the same program, but it's no different than the capability of such modules as Inline::C and Inline::Python in Perl, and doesn't actually involve natively implementing a Perl interpreter.
I am a Perl user not Raku, and Perl had almost the opposite problem where its threads are concurrent but too badly designed to be useful. But from what I have seen, Raku is second to none in this capability.
The other difference is that they did not split into a python 2 and python 3 dev team over the period of two decades which then both decided to keep officially developing their respective languages.
The entire point is to align the name with the reality so that people don't make the exact mistake you made here of thinking that it's a "version update" for Perl.
It is both, but it is the only correct reflection of the current reality. Trying to pretend it's the same language will only end in (further) confusion and disappointment.
As a counterpoint, I'll extend an invitation for anyone to come see for themselves how "unfriendly" the channel is, keeping in mind that it's a two way street and nobody is being paid to put up with you.
It is static rendered HTML. But https://perldoc.pl is dynamically rendered (it is a Mojolicious app) and the difference is not noticeable to me except on huge pages. perldoc.perl.org before the refresh was already static HTML but very slow. I think there is a lot more to it than deployment strategy.