I appreciate Jesse's blend of pragmatism in both keeping working things working as well as the willingness to change things that aren't working. His plan is more conservative than my idealism likes, which means it's probably a wise approach.
The last lines of his plan are telling:
We're awesome at modules. Where possible, we should be modularizing core features.
I've argued before that the most successful feature of Perl 5 enabled and encouraged the growth of the CPAN. (Michael Peppler's 20 Years of Sybperl is a good history lesson of the dark ages before Perl 5 and the CPAN existed.) Even though the original philosophical goals of Perl 5 reached a local maxima in Perl 5, never to overcome gravity until Perl 6, the ability to subvert and extend the language through CPAN has kept Perl 5 alive and thriving far beyond the point most people would have thought in 2000.
Yet Jesse's also right that features such as System V IPC, formats,
tie, et cetera are superfluous to a lot of uses. So are the Perl 4
compatibility libraries that have gone untouched in the core since Perl 4.
A slimmer, trimmer, smarter Perl 5 core could be more agile. It's likely to be easier to maintain. It's almost certainly easier to port to other virtual machines (and yes, this is an excellent long term survival strategy, though you must balance the short term needs against it). Even the discipline of figuring out how to improve the current extension mechanisms can lead to better code.
It's merely a terrible amount of work, and the history of the CPAN demonstrates that throwing willing volunteers at necessary projects eventually gets the work done in a sufficient way.
One of the best places to start is to help figuring out how to smoke test significant portions of the CPAN against bleadperl topic branches. If you have access to bandwidth and significant computing resources (or at least the knowledge of how to parallelize an embarrasingly parallel task like this), p5p could use you.