The fundamental assumption of the CPAN that makes managing software through CPAN clients difficult is that newer software can always replace older software.
That's not the CPAN's problem, not really. Perl 5 has this version number problem too, and it's the source of much of the backwards compatibility troubles in the Perl 5 world.
On the CPAN, no one agrees on what version numbers mean. No one agrees on backwards compatibility concerns. No one agrees about what makes one release "stable" and another release "testing" or what you can change in an API.
I'm not sure it's the job of CPAN or the CPAN maintainers to try to solve this problem. The lack of rules and ceremony over the function of uploaded code and the loose agreement on the form of uploaded code have allowed CPAN to thrive where other languages with their own packaging and distribution systems have fragmented into incompatible, warring fiefdoms.
Even still, fighting over whether
Module::Build is of the devil
because (insert silly reason here) or complaining that
Module::Install is a stupid patch over a pile of nasty, almost
unsupported hacks misses the real point. The best possible improvement in the
Perl 5/CPAN ecosystem is to know which versions of which distributions work
together, and for end users to be able to download a known-working graph of
their desired distribution and its dependencies.
In other words, the big problem isn't that
a nicer interface (arguable) or
ExtUtils::MakeMaker is a horrific
pile of barely-working hacks that shouldn't have survived into the 21st century
(indisputable). The problem is the integration of separate components managed
by separate maintainers with wildly disparate ideas of the semantics of change
over indeterminate periods of time.
At any single given point in time, any given CPAN distribution should work correctly with its currently available upstream dependencies. With the current system, we cannot guarantee that perturbation in those dependency graphs will percolate to users at any point in the future.
In my mind, arguing over whether an improvement to the CPAN ecosystem can take over for every use case of the current tools is stupid and wrong (or, more charitably, a silly distraction). Improving the user and developer experiences of the current tools and the current system is good, but the real improvements in the system will not occur at the interface level.
(Of course, the problem with Adam's point of view is that requiring any credible replacement to handle every possible failure case before stamping it with an imprimatur is that "better" is not an all or nothing concern. I have no illusion that it's possible to fix the Perl 5 versioning scheme for every case. If we can fix it for 90% of cases, surely that's a reasonable improvement.)