and if this state can be set in a way that it leaks out and influences builds later in time, then it's an ugly bug feasting on programmer nerves and time.
This would be true only if "a software" was equivalent to "an ASDF system." That is not the case. I have seen many applications that are made up of a large number of ASDF systems, because ASDF does not necessarily provide nice structures for large applications. In such
we also have libs with 10+ asdf systems.
application builds, you WANT state to bleed from one ASDF system to another, because these ASDF systems are not freestanding entities.
one can write a trivial loader file that calls ASDF with some extra keyword parameters to load such systems.
Complaining that state leaks in and out of these systems is like complaining that state leaks into a closure. It's intended to leak, and that is not a bug.
the vast majority of the asdf systems don't want leakage, and defaults should be covering the majority use-case (if/when it's possible without setting up landmines).
reproducible builds are a valuable feature.
if i wanted to cater for the use-case you described then i'd still make full isolation the default with features to let systems explicitly turn off specific isolations, or just simply let them on their own to subclass and customize ASDF the way we currently have to subclass and customize asdf to avoid the leakage from the hu.dwim.* universe (we use e.g. readtable customizations).
and whoever is not ready to invest time in following the changes, should simply not upgrade, and then it's a non-issue. but this starts to feel like preaching and i don't really have that much stake in this anymore because we have already invested in covering our bases... so, these are just some 0.02...