Comment 17 for bug 1335323

First, understand that the cache is only enabled around a single asdf API call. It doesn't persist from one call to the next. What it does is ensuring that the filesystem is only accessed once per component, and expensive computations only done once (e.g. transitive component-depends-on computations for bundles or warnings check), providing both speed and coherent semantics (and indeed, guaranteed termination) in the face of potential side-effects to the filesystem or configuration in the middle of the build.

Note however that for the sake of faking time notably, the cache is enabled around all asdf test scripts and needs be explicitly disabled when not wanted in the script.

Yes, the cache is important for ordinary users and not just for large users, though it may only save them a tenfold slowdown rather than a hundred-fold slowdown (NB: back when I was writing ASDF 3, my "complex" test system was IOlib, and the cache made a notable difference for it).

Once again, the caching of find-system replaces the old with-system-definitions, without which there are known cases of infinite loops; see notably test/test-xach-update-bug.script

The proposed patch of not doing negative caching should be innocuous enough and not break any existing functionality. I'm just not convince that it's the right thing to do as compared to requiring whoever wants this behavior to explicitly (clear-defined-system name).

If you install foo 1.1 with foo.asd at the same truename as the previous 1.0, asdf will see the change. If the truename has changed, it won't see the new one unless you initialize-source-registry.

If you somehow filled the cache line for BAR and BAZ with NIL, you may need to clear the cache line if you install them within the same session. What I don't understand is why, if Quicklisp has a function in s-d-s-f, said function ever returns NIL on a system that is not installed yet rather than install the system and return it.