“The trick,” for the Perl-6 project, is how to make it a different-and-better language while also allowing it to be source-compatible in some way with its important installed-base ... namely, CPAN.   There is too much in CPAN to allow all of that stuff to be “rewritten.” So, there is a formidable engineering challenge here.   Existing projects such as (specifically...) Moose do show what can be accomplished, even in the context of Perl-5.

So, IMHO, “Perl-6 must be more than a forward step.   It must be a broader step.”   If it were merely to be thought of as “a new and therefore better language,” well, we’ve had all of those things before.   We’ve got them right now.   Ruby.   Haskell.   Your Opinion May Vary.™   All of them, nevertheless, different, and all of them rebuilding from scratch a thing that Perl has spent the last X years already doing.   So, the engineering problem, as it turns out, is in the existing code.   The existing shared code.   The easiest approach of course is to “start with none,” but that is throwing away the baby.   The language isn’t the baby; it isn’t a thing that can be “improved upon” in isolation.   The commercially valuable thing is CPAN, not to mention millions of vital “legacy code” installations that are literally hauling the freight and paying the bills.   Hence, my observation that the approach must be a broader approach:   one that encompasses what exists now, and which elaborates upon it without repudiating it.   We cannot say, “that was then, this is now.”   We need, “that was now, and this is also now.”   A vastly more complex software-engineering problem . . .