As it stands now, cabal's constraint solver will prevent the installation of a package that indirectly depends on two different versions of the same package. This is too bad, because it is not necessarily true the package will fail to install.
Ideally cabal could somehow know which types are exported and which are not. In lieu of that, I personally I would prefer to have a chance of a successful install, and get a compiler error if things really do conflict, instead of a conservative constraint solver error.
Hopefully Yesod will also (if/when this Backpack thing comes to fruition) expose some sort of stable interface for, say, the 5.x series. I think Michael has been very good about keeping things compatible, given the current constraints on the ecosystem, so I imagine he'd be very interested in declaring a stable interface explicitly if that were possible.
A (naive) example: a built package has the hash derived from the package identity and all dependency hashes at compile / link time.
Currently package are referred to by unique hash that sort of works this way, but there are few unfortunate restrictions in GHC and cabal that need to be lifted to allow future installations to not conflict with past installations (multiple instances of the same version, right now there can only be one foo-0.1.0.0 even though it also has a unique hash).
If the fingerprints can be made precise enough, binary caches can be distributed from trusted parties, similar to what other package managers do.