So what you want in fact is a really stable distribution of Perl? If what you needed works only in Perl 5.5.x, even that branch is still maintained, or rather, still mostly compiles on a lot of platforms. If you move within Perl5 releases, some breakage is to be expected in my opinion - that's why Perl 5.5.x still has a "maintenance branch", even though 5.5.4 had as its main change some fixes for gcc compatibility.

The Debian folks never got the spirit of Perl in my opinion, as they never released their modules and applications onto the CPAN, which makes integrating their modules with newer Perls quite difficult. But what you consider a "quite complicated upgrade path" I consider a triviality, and have made it into a rule: Never change your vendors perl. Upgrading or changing your vendors perl on your own will inevitably lead to a broken Perl installation and most likely to malfunctioning system tools too. Perl itself can live quite happily in different versions on the same machine and you should take advantage of that instead of fighting against it. Using Debians (or whatever other) package manager to manage Perl modules is, in my opinion, the wrong way to do things if Perl is central to your objectives. I know that others go the other way and maintain everything through their OS' package tool, but to them, Perl is merely one tool and not the central reason to run an OS.

The "very strong movement" is there because the Perl core is too big, and that's a good reason to want Perl out of an operating systems core. Perl 5.8.10 or 5.8.12 are supposed to get a much smaller core. Anybody doing non-trivial programming in any of the shells incurs a much higher development/bug hunting cost than (competently) using Perl. For a Linux distribution, the higher development cost may pay off in a smaller distribution size.

In the end, I think if you stick with Perl 5.5.x, you get the "real basic and stable" part of Perl on which you can rely. But, as the quote goes, biologists have this special word for "stable": dead - you can't have both, a live and evolving use of the language and its features and a stable set that never changes.

You'll notice that most highly evolved animals use internal skeleton which is mostly dead.

Stable core is good.

If we are moving into the realm of obscure analogies, I'll equate the change in the behaviour of the regular expression engine with the feature of having hairs on the second finger segments. From what I know, this is hereditary, but most people don't care about this feature.

And I've encountered some features, described in camel book(s), which just don't work in some (or most, or modern ) versions of perl, for example:

001  while ($sth=~/sth(sth)/g)
002   {}

shortcut. This used to work in 5.000, stopped working in 5.6 because of broken optimisation. I reported the bug, but apparently this was considered a buglet, and left as is.

This forced me, (and for example Apache::ASP project) to instead use unefficient replacement:

001  $mycopyofstring=$sth;
002  while ($mycopyofstring=~s/sth(sth)/) {
003  }

The point here, is that important features of language appear and disappear at will, thus you've got to stay in-loop all the time, keeping and eye on changes, hoping that what you've learned won't be thrown out of the window next sumer.

I don't know about “experimental”, but was that behaviour ever documented? (Whatever it is, anyway, because I don't really understand what in particular the sample snippets are supposed to be doing or not doing, either.)

Makeshifts last the longest.