Well, if we change the API to add a boolean slot to SYSTEM, we could
this may be naive, but what i meant is a very simple change: introduce an exported SYSTEM-MUTABLE-P, together with a SETF version, that messes around with the current hashtable based implementation.
IOW, it's pretty much just a rename of REGISTER-IMMUTABLE-SYSTEM -> (SETF SYSTEM-MUTABLE-P), and a new SYSTEM-MUTABLE-P that queries the internal hashtable. the (setf ... false) version may be a not-yet-implemented error if there's too much state to mess around with before this release.
moving to a slot based implementation is another story that can be delayed, and may not even be preferable (e.g. what if someone sometimes wants a set of systems to be immutable, and some other time not? although, this also applies to every slot of SYSTEM, so...).
remove REGISTER-IMMUTABLE-SYSTEM, and make it the responsibility of the user to create the system, whether through register-preloaded-system or not. Actually, if the slot has an initarg keyword, then you can use register-preloaded-system directly to create an immutable system if not already present, or you'll have to use setf to make an otherwise existing one immutable.
I'd rather you just release what we have for now, but if you want, I can make those changes before 3.1.5 (or after).
another alternative is to just keep all these symbols private and delay their exporting. optionally multiple variants could be added but not exported, so that early adaptors can already use the to-be-published API by using ASDF:: prefix. probably it's only the two of us participating in this thread who are using this new feature.
an untested sketch is attached that merely renames what's already there, and errors at (setf ... false).
but to reiterate: i don't have hard feelings about this. i'm just trying to help avoiding the publishing of a confusing name that will be much harder to change down the road.