I think the Right Thing is to realize that what ASDF does is not so much transform files, as to maintain the consistency of the running lisp image. Now, in no case does the running lisp image need either the JSON generation system or the JSON to lisp translation system. All the running lisp image needs to function correctly is an up-to-date lisp file produced by this pipeline. So....
this is a very useful insight, thanks for formulating it explicitly! it's a good candidate for an introductory bird's eye view section of the manual.
i already made the JSON generation a separate operation, and now i'm considering to do the same with the JSON -> lisp generation.
in a way it makes sense: the lib author tested the code that he saw. if the lisp generation gets changed/fixed (by a new patch to CFFI), it may even break the rest of the lib that may be running with some old assumptions... so, maybe it's better to just make both of those as a separate process that needs to be initiated by the lib author explicitly, and then checked into the git history.
Once you think about what ASDF does and doesn't do, I think this makes perfect sense. But, of course, it might be a big pain to do so.
yeah, it feels like a lot of pain. it would be nice if there was a fork-like API in ASDF for implementing such exec'd compilation, but then i guess ASDF itself has no clue which /foo/bin/ directory has the underlying lisp binary, and/or which lisp to launch at all, let alone how...