The two most usable examples (aside from MoarVM, which isn't really connected in any clear way, as it is the current mainline VM implementation for Perl 6), cperl and RPerl, are by two different developers, with different but occasionally overlapping goals. The author of cperl posts on HN frequently, so it seems likely he'd have interesting thoughts on this.
The concept of calling a bunch of marginally related and only partly compatible projects "Perl 11" is kinda weird marketing, IMHO. It's been around for a while, and I think it's the author of RPerl's thing.
But, I think it's definitely a situation where the projects are developers scratching their own itch, and diverging in not insignificant ways from mainline Perl 5 (and Perl 6 is not really in the picture for either cperl or RPerl). I don't know that it's a bad thing; Ruby and Python both have forks or implementations that are weird and non-mainline and no one considers them detracting from the Ruby or Python community, in general. Though, none of those projects called themselves Python 5, or whatever.
perl 11 came from 5+6=11, which was Ingy's idea. Will (rperl) and I (cperl, parrot) liked it, so we sticked to it. We are three.
The idea was to come up with something like pypy performance-wise (i.e. parrot done right without all the destruction done later) and perl6 feature-wise.
perl6 is THE picture for cperl, because it has a proper spec for the useful features, to void the usual bike shedding, plaguing p5p since day 10.
The picture for RPerl is not perl6 but performance, proper mapping of perl5 code to C++ data and algos, eliminating run-time magic.
The other projects are doing their thing also, which is fine and encouraging.
Thanks for the clarification. I know Will, as we currently live in the same city, but I haven't followed development of any of the projects mentioned very closely.
The concept of calling a bunch of marginally related and only partly compatible projects "Perl 11" is kinda weird marketing, IMHO. It's been around for a while, and I think it's the author of RPerl's thing.
But, I think it's definitely a situation where the projects are developers scratching their own itch, and diverging in not insignificant ways from mainline Perl 5 (and Perl 6 is not really in the picture for either cperl or RPerl). I don't know that it's a bad thing; Ruby and Python both have forks or implementations that are weird and non-mainline and no one considers them detracting from the Ruby or Python community, in general. Though, none of those projects called themselves Python 5, or whatever.