The most pressing problem about backward compatibility resides in the fact that the community does not seem to understand with exactitude what the backward compatibility needs are. The years have passed and proposed change are tossed away because it might break compatibility. It becomes an easy excuse.
No, I don't think that's true. Maybe I'm too much on the defensive side but I definitely remember several occurences of me having to raise concerns about proposed changes, just for the sake of protecting my own work. So I don't feel the community at large is over-valorizing backward compatibility and really tossing away all propositions.
Unfortunately it's not that simple; my feeling is that several more or less informal groups have different visions about Squeak and actually fight to impose them. Pharo is one such group having divorced from the community because it was tired to fight.
One path out of this confusion would be to have a debate about articulating those different visions, compare them and see what can be done about their differences. I did try, in my clumsy way, to start such a debate, years ago, but it did not work.
That was in 2004, almost 5 years ago:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/086611....
... and reading today what I wrote almost 5 years ago, I see that I don't need to change a word: it's still pretty much the same situation.
The Squeak community wants backward compatibility, so it be. However, it has to be defined in a comprehensive and accurate manner, and no less. I don't want to be served meaningless excuses. Backward compatibility becomes meaningless when it is used broadly and at any moment on a system that never had a defined API, except, perhaps, Smalltalk-80 as a standard.
agreed.
Stef