Or spend years maintaining an abandoned perl version, working around myriads of Unicode bugs, memory leaks in closures and similar hassles?

The original questions shows that he is actively developing stuff, and slowly new versions of CPAN modules require higher minimal perl versions. Which means that you also have to start maintaining old versions of CPAN modules on your own.

Working around a broken environment is a daunting and time killing task. (I didn't program perl when 5.6.1 was state of the art, but from what I heard on various IRC channels it seems to be broken, compared by todays standards and compared to what's available today)

I don't know if there are viable solutions, but continuing to use old stuff certainly isn't very future proof, and the longer you wait the larger your system grows, and the hard it will become to upgrade in the end.

You know, there are situations where people are actively developing code on legacy hardware, where the old version of Perl is so much better than the alternative (Bourne, or if they're lucky, Korn shell), that they're not very likely to buck the hierarchy to try and compile a Perl on the old stuff. For one, the powers that be might not allow you to put a copy of gcc on a "one of" production box.

Things like Solaris 8 have a default Perl of the 5.005 variety. And yes, they get used for production all the time.

It's possible to perform an emergency tracheotomy with a pocket knife and a cheap ballpoint pen, but that doesn't make it a good idea.

I would love to at least be using Perl 5.8 at this point, but I'm subject to two limitations which I cannot control directly (and may only influence indirectly):

1. the Perl version which is standard in the environment where I do my official development work
2. the Perl versions which are standard in the customer environments where my module may be deployed
That's why I'm currently at 5.6.1 - but I don't think my problems are related to my Perl distribution. In fact, you may have addressed my confusion in your first comment (use lib). I'll post another reply when I've had a chance to run some tests.

And don't forget my favorite -- having a vendor of a third party library that you have to use starting development using the newest library only when pushed by their clients.

An application I have to support is about 1-2 years behind supporting newest OS / DB / Perl (for example, they are still validating and compiling against 5.8.x, just released Oracle 10g support in January, and have now clue what the current revision of HP-UX is). We don't do "dot-oh" releases, and we have a boatload of local apps to validate against their release, putting us even further behind.

It is a never ending battle to try to have them find out where we are or would like to go a couple of years out rather than asking the question where are you now (yes, they would ask surveys based on current platforms, and then come to the conclusion that moving forward was not a priority; thankfully the surveys have started to change).