This is a better summary than I gave. To summarize, loading UIOP exposes an error that was always in the version of ASDF in QL/SBCL. It's not a new problem with UIOP or ASDF. I think the issue is exposed because UIOP is so high up in the dependency chain.

Best,
r

On 20 Oct 2017, at 0:25, Faré wrote:

Dear Xach,

I saw your blog post:
http://lispblog.xach.com/post/166534341423/uiop-330-problems

There are no comments on your blog, so I'll just clarify things on the
asdf-devel list:
* The situation you describe is not at all a problem specific to uiop
3.3.0, or any other version of uiop. uiop.asd hasn't changed since
3.2.0, and the "issue" already existed before, and exists when there
is no uiop.asd available but only the builtin uiop.
* The situation you describe, where some libraries are loaded multiple
times, is a bug in ASDF, that was fixed in 3.3.0 --- actually, fixing
this situation and other related situations was the very reason why I
had to teach ASDF about build phases, which lead to the big
refactoring done in 3.3.0.
* All build systems have to either face the issue of build system
extension, or put their head in the sand and do the wrong thing. At
least ASDF 3.3.0 does the right thing now, whereas earlier versions
put their head in the sand as far as that issue was concerned. (I also
know that Bazel has a proper solution, though it involves using a
non-extensible DSL for extensions).
* At least in that case, the issue is not too bad: just some system
recompiled, that will also cause more recompilation the next time, but
don't cause an infinite loop, just a waste of CPU time.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
In Italia i fascisti si dividono in due categorie:
i fascisti e gli antifascisti. — Ennio Flaiano