and I know I will take a hit for saying this out loud

Why do you feel the need to mention that? Being a rebel doesn't gain you anything, being coherent and cogent will. I briefly considered refusing my upvote you otherwise earned, due to this remark.

This segregation would have several benefits:

I don't see these anywhere near as clear-cut. It would certainly not be easier to install a module tree than a single-file module. Maintenance could be easier or it could become harder. Documentation can certainly suffer; I've seen a lot of badly written modularized documentation where you constantly have to crossreference two or three other PODs (and look for the bits in question in those as well, of course) just to find out simple facts. I've also seen huge, very well-written monolithic PODs, though rarely.

.. the glue code required spends time undoing stuff that one module did, in order to supply the intermediate data to the second module which promptly redoes it.

...

There are often inconsistancies within the interface of a single module.

...

.. duplicated functionality as small parts of several modules.

Interface design is what you're complaining about here. Few people are good at interface design. Most interfaces out there, the overwhelming majority of them in fact, suck. Badly.

I say this not as a master of interface design, but as someone who is aware of his own inadequacy. I usually go through at least three iterations of responsibility distribution and interface redesign before I am even close to satisfied with my own code. And I rarely think my results are more than just about usable.

I think most people don't even go into that much effort.

It's like the difference between a top novel writer's books and a pupil's homework essay.

Many modules suffer from bad documentation.

Definitely. Most of them draw a rough and often incomplete sketch of the interface and leave it at that. Rarely do you see any discussion of how the parts fit together, and the joyous occasions there's actually useful, working and helpful example code to look are very few and far between. Ovid's HTML::TokeParser::Simple is one example of well done POD - although I do think the sheer volume of the examples makes the documentation harder to navigate, I've never had any problem looking anything up and finding it quickly. Of course, the self-explanatory interface plays a large part in this too.

All of these boil down to interface design on different levels (documentation is just another kind of abstraction), and aren't really CPAN specific at all. By and large, these problems tend to be just as bad outside the Perl world. We're just in the lucky position to have a well run centralized resource with lots of decent code in it whose concentration makes these issue that much more striking.

Yes, I agree. CPAN is full of half thought out (to put it mildly) stuff. However, I don't think there's any single and certainly no technical solution to these problems. They are not trivial to solve at all. I'm still glad the CPAN exists. The best we can do about it, I believe, is to be aware of the problems, and make an effort to address them in our own work. And of course, to provide feedback - if you have some gripe with a module, go over the source, meditate about it, and produce a suggestion or even a patch (but don't forget to explain your reasoning). Free software thrives on its users' contributions.

Makeshifts last the longest.