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.