Thanks raiph for a good comment. Still, I can't fully hop on your boat.
I truly don't want to be trolling you or anyone here. But some essential principles apply, IMHO.
The team is all volunteer, and that warrants a lot of respect. However, if the team doesn't have as its top goal providing a rock solid runtime that is competitive... then they won't. Filling in Perl5/Python shoes is incredibly hard, and it won't happen while meandering through tasks that volunteers find interesting.
Just like completing a release isn't something that happens "naturally", regardless of the paid or volunteer status of programmers. You need leaders to set clear goals, make hard tradeoffs on the project direction and seduce people to follow them even though the tasks might be boring.
You need release managers to be tough at times and reject fixes, push hard for the release criteria (calendar-based, quality-based, whatever).
My comment about "devs not being desperate to complete a product" speaks about that. Current Perl6 devs seem, by all reports, to be having an interesting time. So perhaps Perl6 is a fun research and (personal) development project. That is swell, and in some cases it can overlap with delivering a performing, working product (see git, for example).
Sometimes it doesn't. Lack of clarity and a strong release ten years into it tell me Perl6 is right now an example of the "doesn't" case.
You say that Perl6 will be competitive, and able to fill in Perl5 shoes. IMHO, the current course won't lead there. Targetting the JVM means Perl6 won't be part of any distro's "base" install, as Perl5 is now on Debian, or Python is on Fedora/RH. It means apt-get install perl6 will show a dep chain that will scare sysadmins. Means you'll start arguing about which JVM to install (with the package manager, with people), and which webserver JVM setup too.
This in turn means that the quirks of Perl6 runtime will be all over the place -- when someone reports a bug, instead of just asking "which perl6 release?", you'll be asking "what JVM? version? using tomcat or mod_java or... ?". It is a horrible place to be, so far up the stack.
And it means that you'll be at most as fast/efficient/performant as Java. That's spectacularly uninteresting to me.
Perl5 set the bar so high it is hard to be competitive in that space. My worry here is not that the Perl6 team carps on how hard it is to get so good. It is that the Perl6 team doesn't seem to be interested in achieving the key goals of what Perl5 achieved.
Perhaps I am a grumpy old man. Don't let the bastards get to you. But also don't forget to decide and tell the world whether your top goal is a fun research project or a useful product. Key distinction between the top goal and secondary goal(s).
(Here, ISTR Larry or Damian saying that Perl6 development was optimized for the fun and enjoyment of the developers. If that is true, then that management style has a risk of forgetting to deliver something of relevance to the outside world...)