We don't agree on #2. Inline::Perl5 is better than I would expect, but there is still an issue. For example, Perl 6 uses garbage collection instead of reference counting so modules like http://search.cpan.org/dist/ReleaseAction/lib/ReleaseAction.... no longer work like they did in Perl 5. (Yes, that module is used in production code. And I happen to know of several independent re-creations of the same functionality that are used in the same ways in other production code.) I am sure there are other examples.
Granted, this a module that depends on a quirk of Perl 5 behavior. But even if only 5% of CPAN modules hit such a nasty quirk, dependency chains are long enough that most non-trivial applications will have some dependency that breaks somewhere. If I have a library that uses DBIx::Class, Moose, and Catalyst with some interesting plugins, would you care to bet money that it will work with no issues under Inline::Perl5?
On #3, what backwards compatibility means is "compatible with what you already have". Perl 6 immediately loses on that to Perl 5 because nobody has Perl 6 legacy code bases. Ideally this wouldn't be an important fact. But it is an important use case. Many organizations today are only staying on Perl because they do not want to rewrite their code. If they hit the point where they would be willing to do a Perl 5 to Perl 6 migration, there is no reason why they wouldn't consider a Perl 5 to Python 3 migration instead.
While I grant you there are probably modules with problems, I will state for the record that I don't consider any module that relies on specific undefined behavior that could stop functioning as expected due to a regular Perl 5 point release to be the problem of Perl 6. If Perl 5 could break or change its functionality by changing exactly when they deal with reference counting and destroy objects, then it's a time bomb in production anyway.
That said, your complaint in #2 was about Perl 6 losing to every other language in library support, but I think we've established it's nowhere near as bad as that. It's not perfect, but it's definitely not barren. There's a few tens of thousands of modules Perl 6 can try to use, and there's a fairly good way of knowing if they will work or not, since most have good tests.
Your original complaint for #3 was also about companies needing to rewrite all their code. I think Inline::Perl5 goes a long way towards addressing that as well. It's not perfect, but when considering "Their primary motivation for staying on Perl is that they don't want to rewrite their code. Perl 6 requires a rewrite of their code." I think it affects that point of view.
I think you have somewhat valid points, I just don't think they are nearly as solid as initially presented.
...module that relies on specific undefined behavior...
You call Perl 5's use of reference counting "undefined behavior"?
It has been documented behavior for as long as Perl 5 has existed. The resulting destruction mechanics have been relied on by the core module http://perldoc.perl.org/SelectSaver.html for the same time. Furthermore any interesting XS program is likely to make use of the relevant macros SVREFCNT_int and SVREFCNT_dec.
Therefore this is NOT something that can be changed in a point release. It is a fundamental part of how Perl 5 works. And the fact that it is a fundamental incompatibility with Perl 6 plans is something that people have been aware of for a decade.
> You call Perl 5's use of reference counting "undefined behavior"?
No, I call counting on the fact that items with no references will be reclaimed (triggering DESTROY) immediately when they go out of scope undefined behavior. The fact that it happens very fast in most cases because it's reference counted and not garbage collected is not something that should be counted on. In fact, I'm pretty sure there are cases where in very tight loops, DESTROY isn't called immediately on scope end. I vaguely recall having to deal with that problem (but it could just as likely been a bug of mine that appeared to indicate that until I found it).
Followup, since it's too long since my reply to edit:
How are you assuming Inline::Perl5 works? Did you look into it and these are issues you found, or are these from how you assume it works?
Inline::Perl5 spins up an embedded perl5 interpreter (libperl I assume), and handles the data marshaling transparently. I assume (having not looked too closely at it's implementation), that it's sort of like a reverse XS. It looks into the perl5 guts, runs perl5 code, and exposes variables and functions to Perl 6. I see no reason to assume it wouldn't be using SVREFCNT_int and SVREFCNT_dec or equivalents as needed on scope changes to handle this.
In fact, looking at the Inline::perl5 repo now, it appears they are doing quite a bit with the refcnt functions[1].
We don't agree on #2. Inline::Perl5 is better than I would expect, but there is still an issue. For example, Perl 6 uses garbage collection instead of reference counting so modules like http://search.cpan.org/dist/ReleaseAction/lib/ReleaseAction.... no longer work like they did in Perl 5. (Yes, that module is used in production code. And I happen to know of several independent re-creations of the same functionality that are used in the same ways in other production code.) I am sure there are other examples.
Granted, this a module that depends on a quirk of Perl 5 behavior. But even if only 5% of CPAN modules hit such a nasty quirk, dependency chains are long enough that most non-trivial applications will have some dependency that breaks somewhere. If I have a library that uses DBIx::Class, Moose, and Catalyst with some interesting plugins, would you care to bet money that it will work with no issues under Inline::Perl5?
On #3, what backwards compatibility means is "compatible with what you already have". Perl 6 immediately loses on that to Perl 5 because nobody has Perl 6 legacy code bases. Ideally this wouldn't be an important fact. But it is an important use case. Many organizations today are only staying on Perl because they do not want to rewrite their code. If they hit the point where they would be willing to do a Perl 5 to Perl 6 migration, there is no reason why they wouldn't consider a Perl 5 to Python 3 migration instead.