Hi Andreas,
Honestly, Stef, if it isn't random then what is the strategy for these changes? Looking at the past Squeak versions, starting from 3.6 every version was just incompatible enough with previous versions such that it would break any serious user of the metaclass hierarchy (like Tweak). I think you will agree that it can't continue that way, that at some point we need to get back to what can be called a *stable* metaclass kernel with reliable APIs and when exactly will that point be reached?
my vision of squeak is a live organism and I don't think a stable API could fit such a system. I agree with you that one should be able to rely on a common factor and work on top of this. On a certain point of view this is already done with the most common classes/hierarchies and their methods (you can count on #do: and #collect: for the collections, and on #superclass for Behavior). But squeak is not in a position of stabilization. Its community is to small. Currently, I think it is better to push things and make things go ahead even if it breaks compatibility.