Originally, I was very concerned to minimize the overhead of dependencies for building and testing ASDF, and I still think this is important.
But I now conclude that trying to pull in the cl-scripting infrastructure was wrong, because it had the side effect of making the system used for testing be a dependency of the system under test, introducing unhealthy circularities.
Going forward, if you want to experiment further along these lines, I'd suggest an entirely separate project -- with its own test suite! -- that would build an executable capable of executing CL scripts. That executable would have to NOT require bleeding-edge ASDF capabilities, only simple core capabilities. It should be built with the ASDF that's delivered with implementations, not with bleeding-edge ASDF.
That executable could be built, saved, tested, and installed, and then could be used as the engine for ASDF building, testing, etc., if one liked. It could be a required build tool, the way today "make" is a required build tool.
To be honest, I think such an engine should first be tested with much less demanding problems than building and testing ASDF. Simple scripting tasks, say within the ambit of the /Perl Cookbook/, would be a reasonable starting point.
Even doing this, I think there's only a 50-50 chance the approach will work out. CL's numerous incapabilities where dealing with the host OS and filesystem will still stand in the way. Committing to a single implementation -- probably CCL or SBCL -- might solve this problem. A less cumbersome means of line-by-line processing of streams should be developed, and some means of using regexp literals should be added. Variable interpolation into strings should be provided.
Just some thoughts....
Best, r