The big problem, however, in this case, is still how do you distinguish between a "good" class that shouldn't trigger a warning, and a "bad" class that should.
By deprecating the use of operation as a superclass, and providing a new ‘new-operation class (or some such) that user code has to use instead. (new-operation could be a subclass of operation…)
I'm not sure this helps at all: * For code going forward, that could be a signalling mechanism — but going forward, whichever way we do it is easy, since people who today are hacking for ASDF2 and not ASDF3 are responsible for their own problems, really. * For existing code, it doesn't help, since that code already exists, and the problem is precisely to distinguish between the good code and the bad code if any is left. * As a general versioning mechanism, I don't think that introducing operation-v3, operation-v4, operation-v5 is a good way to distinguish between good and bad code as we evolve the hierarchy, especially since actual code will likely already inherit from one of the subclasses, in which case it automatically gets the new superclass, which then can't be used as a reliable discriminating criterion.
The thing is, CLOS simply doesn't have any standardized mechanism to deal with code versioning, though it does provide the low-level hooks to deal with data upgrade, and you can probably build your versioning system on top of it. I'd love it if there were a mechanism, and if ASDF could use it, and/or be a platform to discover it. But in the meantime, we shouldn't expect ASDF to do more than is possible. ASDF is always doing so much more than most software in terms of static and dynamic version compatibility and upgrade!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "To alcohol! The cause of... and solution to all of life's problems!" — Homer Simpson, quoted by H. Duray about Addiction to Government