The best we can hope for is probably a slow, relentless refactoring.

Relentless I agree with; but I question "slow".

It is my (long) considered opinion that if you reduce the targets to Windows and *nix (I'd say POSIX, but that lives about a decade behind (at least) linux); then with just 10 people (They'd have to be the right people), you could refactor perl5 in one year, to be:

• Faster.
• Simpler.
• More maintainable.

The secret: Fcuk the rest; get it working on these two first.

Rational: If it can be made to work -- ie. passes the entire perl build test suite and perlbench on those two platforms, whilst having reduce the kloc by 50% and the average function size by 50%-- on those two wildly disparate platforms, then it can be made to work anywhere where there is sufficient will and bodies to tackle the task. (If there ain't; c'est la vie!)

Detail: Whilst neither kloc nor function size is directly proportional to understanding, correctness and maintainability ; the correlation is so strong, over many studies over many decades, that it would be obtuse not to recognise that simplification is inversely proportional to understanding; and understanding is directly proportional to both correctness and maintainability.

Target: Start small in terms of platforms (just two); start small in terms of functionality (just does what p5 does now); start small in terms reduction in size. I've suggested 50% but I believe 70% is (quite easily) achievable.

If you reduce the current code by 50%; twice as many people stand a chance of understanding it.

Then you emulate the pugs model: everyone gets a commit bit; (a majority of) 3 people have to agree, to rescind a commit.

The guiding logic

Nothing substantial -- syntax or semantic -- changes until a 50% reduction (compiled kloc) occurs. Then you invite both requests-for-change, and patches.