(or burying the lede on a Saturday morning)
If Perl 5 is a language (and not just an interpreter), how fast should that language evolve and what "versioning" signifies significant change.
One reason people debate so hotly the naming of "Perl 6" is the magic tied to a version number. I've written many times that "Perl 5 can never break backwards compatibility in a radical way because it's never broken backwards compatibility before." That's a common belief. It's also a common belief that it's only okay to correct some of the flaws of Perl 5 (especially missing defaults) by breaking backwards compatibility and signifying that change by incrementing a magical version number.
Of course a number is just a number and a version is just a version and a belief—no matter how wide spread—is just a belief. It may even be a myth. Certainly it's falsifiable.
One little change to Perl 5 would instantly make all of these things
possible without requiring Larry to invoke rule #2 on the naming of
Perl 6: if Perl 5.16 (or 5.18) required the explicit declaration of
the version of Perl 5 any particular file or lexical scope used and defaulted
to "whatever the most current version of the
perl binary used to
run the program provides".
That simple act of declaration (and not-quite-heroic work for backwards compatibility pushed the direction it belongs instead of externalized from the enterprisey to volunteers) could solve so many problems. All it takes is a slight shift in culture and character and, yes, belief.
Fortunately, Jesse Vincent's plans for 5.16 and beyond represent the kind of change of narrative Perl 5 needs, regardless of what happens with Perl 6.