In general, we'd much rather depend on a solid, tested module than poorly implement half of its functionality.

And there's the crux of the problem.

If you would only need to (poorly*) implement half of a module's functionality, then it means that by using it, your are also loading the other half of its functionality that you do not need. And that is deadweight.

It's like having: a people carrier for the seats; and a Ferrari for the speed; and a Rolls for the fridge; and a Citreon for the ride; and a Beemer for the Stereo; and a Volvo for the safety; and a Astra for the bike carrier; and a Polo for the iPod interface; and then loading them all onto a 40-ton car transporter and driving around in that to ensure you have everything you need!

The problem with many of these modules is that their basic functionality--the stuff you want--is relatively small, but the authors feel funny about putting a module on CPAN that only contains one or two small routines, so they add 3 or 4 other flavours of the basic routines that people "might find useful". And by the time you've loaded up a dozen dependancies, you've got 1/2 a meg of stuff you need, and 10 meg of stuff you never use.

If module authors used the Autoloader & Autosplit modules (as exemplified by modules like POSIX), so that their users could select what they need at compile time--or just stuck to providing the good bits without adding all the frills--then at least the problems of runtime bloat would recede.

(*)Why does it have to be poorly implemented? You have the good implementation as a crib. One possibility would be to produce a Moose::Utils module that extracts (and tailors) just the bits of your dependancies that you use, and ship that with Moose instead of the dependancies.

• Moose gets just what it needs--which helps your start-up delays and runtime bloat problems.
• Moose users get less dependancies and more performance.
• Moose developers and users benefit from not suffering the vagries of random authors making random changes.
• As dependancy modules change through upgrades and bug fixes, they can be integrated back into the Utils package in a controlled fashion--if needed.
• Moose benefits from not suffering breaks, because of accidental reliance upon bugs that get fixed.
• And it affords the opportunity to tune, prune and even improve those dependancies in ways that might even be useful fed back to the originating modules--without stalling your improvements waiting for author approval or tuits.

I realise that the idea of C&P reuse is an anathema most places, but re-use can be taken too far. The head/side/taillight requirements of most cars are pretty much standard, but the units are rarely re-used--even between models of the same manufacturer. The other criteria of the overall design--aerodynamics; aesthetics; etc.--dictate against such re-used despite the common requirements. The bulbs get re-used though!