Curiosity about a general solution is what prompted this thread,
Oh well, I'm not going to expect much to come out of it, then.
With respect to package renaming, I've asked Michał Herda to comment on whatever issues he'd had with "destructive package renaming" [1]. I understand it as referring to the state-based global-reader implementation of packages, which seems to entail well known problems like reentrancy and readtable leakage.
No, I use rename-package, but I leave it as the programmer's responsibility to ensure that a package's canonical name while compiling a fasl will be a valid name for the correct package at load time. In the general case, this might entail instrumentation or shadowing of defpackage and make-package. No reader hack necessary.
[The XCVB] approach sounds like one motivated by version conflict between the build system and system being built. Is that correct?
Yes. Having lots of dependencies means that "interesting" things may happen if you start compiling an incompatible version of a library you're using. Or even a compatible version that resets important data structures in one file that will only be filled in in another.
I wasn't really thinking about that, but now that I am I'm reminded of various parts of your paper [2]. The bootstrapping, upgrading, and distribution of ASDF seems very thorny indeed.
Indeed. Thanks for being a good public.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A president worth voting for wouldn't run for office.