> people with Unix heritage are likely to be quite resistant to anything that needs a JVM to run
Perl 6 does not need a JVM to run.
I agree that many who might accept a technically adequate Rakudo/Parrot might balk at a technically adequate Rakudo/JVM that was (perceived to be) proprietary.
> I personally appreciate the idea of using JVM
There will likely soon be a Rakudo/JVM.
> one really good thing about java is that there's a ton of good libraries written for this language, so that would immediately seed a pretty big "JPAN" for Perl 6. However, in order to *really* benefit from that, the usage of those classes should be as transparent and easy as humanly possible.
Rakudo/JVM is supposed to just be a stepping stone to A) completion of the Perl 6 spec (in particular concurrency) and B) porting to other backends. It's not necessarily interesting to jnthn (the guy doing the port) beyond these short term roles. But you're right that it may get more interesting than that. We'll see.
> With 6, is it still true that only perl can parse Perl?
From a theoretical perspective, the situation is basically the same. (Perl 6 has gone further down this road, with features like lisp-style macros that mean that Perl 6, just like Perl 5, just like lisps, just like haskell with Template Haskell, theoretically isn't parseable without a full language implementation.)
From a practical perspective, the situation is much better. One shift is what Larry Wall has phrased as "only Perl 6 can parse Perl 6". Note the extra capital 'P', reflecting the fact that Perl 6 is a specification not an implementation which makes a big practical difference. Another is that Perl 6 is a much more regular language than Perl 5.