Remember that the benefit of older perls is larger than you think. The big win is that they are fast. Essentially, if you don't have to deal with Unicode, you don't pay for a lot of overhead. In the C code there is lots of if (unicode) {do_this} else {do_that}. Signal handling has also been made safer since then, at a slight cost in performance.

In fact there have been lots of things added that impose small performance decreases here and there. But the cumulative effect is profound. Consider 6 hypothetical patches to the core. One imposes a 2% decrease, two more impose a 3% decrease, two, a 4% decrease and a final patch makes things run slower by 5%. Doesn't sound too bad? When you add up the effects (0.98 * 0.97 * 0.97 * 0.96 * 0.96 * 0.95)... you discover you've lost 20% performance.

(I'm just playing devil's advocate here... my home machine is running perl 5.10.0).

Of course, if you are doing Unicode you have no choice, but in other circumstances you do.

When a newcomer to Perl looks at a central module or even at a module in core, they see that we are not using the "advanced" features. What message does that give?

This is a false debate. Some of the most scrofulous C code I ever read was source of the standard C library of a compiler (Zortech C, for memory). Not because the programmers were slouches, but because they were held to an imperative of working around bugs in CPUs, operating systems and even their own C compiler. Lots of comments like "can't do foo() here because of...".

So it's hardly surprising that some of the core module code is messy. That's so you don't have to worry, as a client. Systems code is held to a different standard, and looked at through a different lens. I know lots of people don't agree with this, starting with chromatic, but I still believe you can enjoy writing code that forgoes certain language constructs. Poets call this constrained writing.