The problem is not a Lisp problem.  It occurs in many language ecosystems, and it cannot generally be solved.

Things are relatively simple if you just look from the top to the bottom, from the usage of a lower-level library by a higher level library or application functionality.  Such usage could confined to within that tree of a linked application, e.g. by symbol or package renaming or the like, and similar techniques have been tried (in Lisp, but also in JVM languages and most likely elsewhere).

The real issue though is data types defined by versioned libraries.  Suppose that an instance of a data type defined in library A version 1 is passed, through higher levels of the software, to version 2 of that same library.  How would one ever expect that to work?

Faré is completely right:  There is no way to apply some external magic to a hairball of different library versions of libraries and expect the result to work.  The only way to deal with it is to actually address the conflicting versions and make sure that all libraries in a system are prepared to use the same overall set of dependencies.  If a tool can help with detecting conflicts, it is great, and maybe that is what would be a good goal in the CL world to create such a tool and version tagging infrastructure.

I can report that in the Clojure world, every conference that I visited has at least a lightening talk on the subject of library versions and how to deal with them.  I have yet to see one where the presenter claims to have a solution, and most of these talks end up concluding that there is a possible problem which cannot generally be solved, but that many Clojure shops get away ignoring the problem.  We have been using the leiningen build tool to help us finding library version conflicts and generally strive towards smaller systems to reduce the number of dependencies that we need to synchronize, version-wise.

-Hans