Dear Robert,
you seem to be complaining about issues inherent in any shared namespace, where names can clash. There is no "solution" to that. That's a *whole point* of a namespace that names may be bound to different values, and that incompatible values *shall* clash. Not a bug, a feature!
One could imagine that with real first-class namespaces, it should be easier to implement dynamic binding of such names, static binding in lexical scopes, virtualization, etc. Thus, within a same image you could have several binding-sets, and though every binding-set contains compatible bindings, different binding-sets could be mutually incompatible without problem (as long as you don't try to have data from one binding-set interoperate with incompatible code from another). Happily or unhappily, CL has no such provision in its package system.
If you want to develop some kind of "better module system" on top of CL, good luck with that: you will have to not only create something that is indeed technically better, but you thereafter have to convince other people to use it so you may benefit from it — and you'll probably have to start creating a massive body of work using your system before people even look at it. I fear the global side-effectful nature of CL will make it very hard to keep anything clean on top of CL, but I'm looking forward to what you have to offer.
Personally, I'll say that lisp-interface-library (aka lil) was started as a demo of how you could write more modular code in CL. By modular, here, I mean that you can define interfaces and multiple implementations of those interfaces, what more with parametric polymorphism as well as ad hoc polymorphism. While I think of lil as a technical success, I certainly failed to produce a massive amount of software using it, and have therefore not gotten many people interested in extending it (though I have a handful of contributors). Such interfaces offer a solution to the problem of allowing the peaceful coexistence of multiple instances of solutions to an existing problem. They of course cannot solve the issue of these multiple solutions claiming the same name; if you want multiple versions of an interface implementation, they need different names, though you're welcome to use some version as part of the names.
PS: If you have concrete ideas on how to improve ASDF and/or Quicklisp, there are more specialized mailing-lists and/or bug tracking systems for that. For instance, you may propose some kind of off-the-side version tracking and version incompatibility tracking to ASDF, to express constraints that you can't retroactively include in the systems themselves.
PPS: You might be interested in reading my blog post about build systems, especially the part discussing programming in the large. http://ngnghm.github.io/blog/2016/04/26/chapter-9-build-systems/
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org As for poverty, no one need be ashamed to admit it: the real shame is in not taking practical measures to escape from it. — Perikles, speaking about the poverty of CL regarding modularity solutions