Hi Rudi,
I see similar errors in other situations. My guess is that at load time,
classes get redefined but object literals from compile-time (with the compile-time class) stay around in the fasl. These literals then have (come load-time) a class with the same name but different identity than the one that find-class returns.
Thinking about this assumption, I'm still very much puzzled what in our code base would instate an object of class METHOD-COMBINATION. That is, not of one of its two subclasses (SHORT-* or LONG-*), but of the direct type.
From what I searched our code base I can't find any code which would do
that (i.e. instantiate an object of that type).
Also, when looking at the MACROEXPAND-ALL output of DEFINE-METHOD-COMBINATION, DEFGENERIC and DEFMETHOD, there don't seem to be any direct references to any objects or classes. E.g. the method combination designation in DEFGENERIC gets saved as a symbol which is passed through to our internal %DEFGENERIC function which is called upon evaluation of the DEFGENERIC form be it compiled or interpreted.
Also, compilation of DEFINE-METHOD-COMBINATION, DEFGENERIC and DEFMETHOD don't have any other compile-time side effects than that the symbol of the generic function is (temporarily) assigned a function to its symbol function slot. Meaning D-M-C compilation is completely compile-time side effect free, as far as I can tell. Which would be completely contrary to your expectation.
So, I'm still very puzzled. What would be our best way forward? I'd love to fix this, because I think we'll run into it later as well in "real world" cases. Would getting together on IRC to chat about it be a good next step? (One issue that I see is that all these tests used to pass when I wrote them. So at some point something must have changed which made us incompatible with ourselves. That's another reason why I at least want to understand what's going on...)
Bye,
Erik.