This would be coupled (here's the icky part) with a PERFORM method that does nothing, because by the time it's invoked the make will already have run.
That's not the icky part. The icky part is OPERATION-DONE-P lying to ASDF.
I have been mulling this over, and here's what is interesting to me about this case:
The ASDF protocol has OPERATION-DONE-P, which is used as NOT-OPERATION-NEEDS-DOING-P. I.e., if it returns a non-NIL value, when applied to operation O and component C, we may skip doing O on C.
For my MADE-FILE, I cannot[*] compute the answer to this question: all I can do is compute a conservative bound on OPERATION-NEEDS-DOING-P. In fact, all I can compute is a degenerate bound: I assume that OPERATION-NEEDS-DOING-P is always true.
Now, let's assume we have another operation, O', and component C', and we have to do O'(C') if O(C) did something.
The problem here arises because ASDF assumes DID-SOMETHING-P(O,C) == OPERATION-NEEDS-DOING-P(O,C). That is, ASDF assumes that if it BELIEVED it needed to do O to C, then something will have changed AFTER it does O to C.
In the case of a MADE-FILE (and some other possible ASDF components?), this is not the case. Since we are conservative about whether or not O(C) needs doing, sometimes we are wrong and after we apply O to C, nothing has changed.
Furthermore, for MADE-FILE, it is possible to examine the filesystem *AFTER* O(C) and determine a *better answer* to the DID-SOMETHING-P query than we can for OPERATION-NEEDS-DOING.
Unfortunately, there's no room in the ASDF protocol to do this. But it would not be impossible to modify the protocol to make it happen, and this could be done in a backwards-compatible way, by having OEPRATION-DID-SOMETHING return the value of OPERATION-DONE-P before the operation by default...
I'm not sure that this is worth doing: it would depend on whether there are enough interesting cases where OPERATION-DONE-P (approximate!) and OPERATION-DID-SOMETHING diverge.
cheers, r