I have found that there are three classes of site-specific libraries that get developed.

1. Kitchen Sink Utility Libraries
2. Chunk Libraries
3. Interface Libraries

Yes, you can chalk it all up to 'good documentation'. :D Seriously, the only ones that I see getting out of hand are the KSL group, because they really have no cohesive purpose. Chunk and Interface Libraries do have such a cohesion and are constrained by their functional purpose and API, respectively.

I tried once to separate out KS functionality, much as C does with its #includes, but the only way that worked was when I enforced use of a program template that had them all pre-embedded. Until I did that, everybody quickly made use KitchenSink; which was itself a bunch of use foo; calls. Perl programmers ARE lazy (otherwise we'd all be J^v^ or C++ coders), but that's part of the reason why we're GOOD.

The point has been made that the goal is to develop a large application. Coders of any stripe DO need to concentrate their attention, and it is rare that concentrating on the meta-hierarchy can be sustained even by the best of us. Some coders are better at that than others, and I think you need to accept that completing your project will require identifying the few that can hold multilevel system analyses in their head and giving them the task of maintaining the libraries. This is generally a burst-mode activity and you need to make your managers understand that these guys are working hard -- or recovering from such -- when they're staring off into space. Those that aren't comfortable with this can also be good and productive coders, but you need to keep them focused on one level where their linear thinking and planar grasp of relationships can be applied effectively.

So, to summarize: document thoroughly, divide up your tasking to maximize people effectiveness, and explain this last to your management well.