James Anderson has asked for a "concise statement of the issue at hand."
Faré has had to change the semantics of the OPERATION class. Previously, the OPERATION class would automatically trigger dependencies downward (notably, if you did an OPERATION on a system, then you had to do that OPERATION as well on that OPERATION's children), "leftward," and onto itself ("selfward").
The implementation of this left holes, and also caused problems for extensions (e.g., for TEST-OP, one typically had to define a default PERFORM that did nothing, since testing a system necessarily tested all of the files).
To fix this, Faré had to add new mixin classes, DOWNWARD-OPERATION, UPWARD-OPERATION, SIDEWAY-OPERATION, and SELFWARD-OPERATION.
In order to preserve the integrity of the code, OPERATION remained as the superclass of all operation objects. But its semantics has changed.
This is not a problem for anyone with a "vanilla" ASDF system. The only programmers who are vulnerable to this change are those who have defined their own subclasses of OPERATION (or those who use libraries whose programmers have defined subclasses of OPERATION).
For those cases, I have pushed a change that checks to make sure that all operations that are instantiated are subclasses of either DOWNWARD-OPERATION, UPWARD-OPERATION, SIDEWAY-OPERATION, SELFWARD-OPERATION, or a new NON-PROPAGATING-OPERATION. If this run-time test fails, an error will be signaled and the programmer will have to fix the offending OPERATION subclass's definition.