The most significant feature added to Perl 5 (released on 17 October 1994) is the module system. No longer did Perl programmers have to manage a series of .pl files mishmashed together into a library system. That change—organizing code into reusable, composable libraries—enabled the growth of the CPAN and almost every good thing which has contributed to the Perl Renaissance.
If you look in the source tree for Perl 5.10.1 (the latest stable release of Perl 5) you'll see a slew of long-forgotten .pl files which shipped with Perl 4. They've been in the core for the past fifteen and a half years, lingering mostly untouched, long superseded by other core libraries and much better distributions on the CPAN.
Given that the Perl testing revolution didn't begin until late 2001, how do you know the old code works? "I don't have to modify it!" isn't a satisfying answer. No one wants to modify it, as shown by the fact that no one has modified it in years.
This code likely won't be in Perl 5.14 (I originally wrote 5.12, but that was obviously false, as Jesse Vincent mentioned). It has a new life on the CPAN as Perl4::CoreLibs, where it can grow or fester, where people can maintain it if they want or ignore it if they don't. (You can predict my prediction.)
Perl 5.12 includes other deprecations, including some core modules spun out to the CPAN where their maintenance burden will no longer affect the core. In Perl 5.12, using them within the core gives deprecation warnings. Installing them from the CPAN does not produce those warnings. (Naturally this has been the point of some contention, though I suspect that anyone who's been writing Perl since at least 1994 knows at least one text processing language to use to update code for the latest version of Perl 5.)
If you need these deprecated modules, install Task::Deprecations::5_12 from the CPAN. (The indexer will catch up with the upload soon; it's not there at the time of writing.)
If you distribute Perl 5, consider whether you want to bundle this module with your installation, or whether your support system should notify your users about this distribution.
If you're upset about this change, if you make heavy use of this code, consider volunteering to support it on the CPAN. Meanwhile, the core gets a little slimmer, a little less crufty, and a little bit easier to maintain. I forgive you for thinking that this helps to contribute to Perl 5.12 coming out less than a year after Perl 5.10.1, because I agree.
A small, but somewhat important factual correction. The Perl 4 libraries in question DO ship with Perl 5.12. They just warn about the fact that we may choose to remove them in a future version of Perl. That may be as soon as 5.14, next year.
Can't believe it - is the ice on perl5 development finally broken? )
Next step: bite the bullet, and distribute Moose in the core libraries and rid us of the 'library hell' that doomed CLOS and other 'basically standard but are add-on' libraries to oblivion.
This is more likely to happen in Perl 5 distributions such as Strawberry or Chocolate Perl. I don't believe p5p wants to take over maintenance (or synchronization of maintenance) of Moose and Class::MOP.
I agree with that concern; I'd like to see far fewer libraries in the core. At the same time, I want to see more or better *features* in the core.
David N. Welton's Where Tcl and Tk Went Wrong reinforces your point about CLOS and bolt-on libraries. That's a tough line to walk.