Proposal: Technique to handle package dependency gridlock

We've got a problem with dependencies:
http://cdsmith.wordpress.com/2011/01/21/a-recap-about-cabal-and-haskell-libraries/
http://cdsmith.wordpress.com/2011/01/17/the-butterfly-effect-in-cabal/
http://www.reddit.com/r/haskell/comments/x4knd/what_is_the_reason_for_haskells_cabal_package/

I'd like to present a proto-proposal for another arrow in our quiver.

First, a few...
Principles:

  This problem isn't uniquely Haskell's
    ...Although it may be uniquely Haskell's to solve. Lots of
languages have a problem managing their package dependencies. To quote
Chris Smith, "it’s fair to say that perhaps Haskell is one of the few
environments where we’ve got a prayer at solving the problem."

  It's a magnitude problem
    The trick is to not find one perfect solution; it's to use enough
effective solutions that the remaining tricky cases can be swept away
individually. Solving the problem will most likely involve several
techniques (good versioning policy, a little work on the part of
package maintainers, smarter Cabal, new tools, etc.). Once we get the
problem down to a manageable level, then it's a problem that can be
dealt with package-by-package.

  Haskell packages are not black boxes
    Inheriting - from the imperative world - the idea of packages as
indivisible units may be a mistake. A language like Ruby may have to
import a full library, because it's nearly-impossible to reason about
the behavior of part of it in isolation from the rest of it. Haskell's