Sean McGrath nails it in Fast Forward to Forward Compatibility. Our community seems to treat backwards compatibility as being a more reasonable target than forwards compatibility. I think there are 2 main reasons why forwards compat is treated in this shabby way, and that this is also dangerous thinking.
The first reason is that backwards compatibility is a language designer-centric view rather than a user view. A language designer that is revising a language almost invariably has more options for backwards compatibility than forwards compatibility. They are, as Scott says, "creating the future" so they have knowlege of both what was in the past (the previous version(s)) and the current (what they are working on). They will write their new whizzbang software to take advantage of the new features - whether its backwards compatible or not - and this is the stuff that is fun/interesting/makes $. Backwards compatibility is something that they can control, but it's really the new features they care about. Their interests lie in the new features, and commensurate new revenue. They will have plenty of incentive to make sure that they are backwards compatible, but they still have choice.
OTOH, designing for forwards compatibility is much harder and much less interesting. When designing a language for forwards compatibility, they must do 2 things: Ensure V1 can handle the future, and make sure that V2 uses the V1 future provisions. This typically means putting extensibility and a processing model for extensibility in.
XML
Look at XML 1.0 and 1.1. XML 1.0 did not allow for forwards compatibility in name characters - the characters are either valid or invalid. XML 1.1 added more name characters than XML 1.0. It broke forwards compatibility because XML 1.0 didn't provide any place for a future version. In hindsight, this seems vaguely surprising because everybody knew that unicode was on a particular development path.
XML 1.1 is *almost* backwards compatible, and they could have easily made it so. They would have found it far easier to enable backwards compatibility because they knew what the past was - the name characters that are allowed - and they knew the current - what the new name characters are.
Now think of the mechanics of the XML 1.1 development. The reason that the name characters were added was to enable a richer i18n experience. There are people who really want the new feature. They have a vested interested in the new feature, and it turns out that they even sacrificed backwards compatibility to get it - though they didn't have too. They had little control over what XML 1.0 provided in terms of forwards compatibility.
Stakeholders
We see how this works: the XML 1.0 authors wanted to ship a spec as soon as possible, and there are very people who would champion forwards-compatibility. How does somebody champion the future? It is very easy for a chair or working group to go "that's nice, but why should I slip my schedule designing for forwards-compat when I don't even know if it will work?" No vested interest in the future.
I believe this is why forwards-compatibility is the black sheep of compatibility: it's hard to sacrifice schedule for some unknown and unpredictable future. Whereas backwards compatibility is a known quanitity for the next version.
Costs
The problem, as Sean describes, is that forwards and backwards compat are generally equally important. In distributed systems, either side can evolve. Let's look at the XML 1.1 example. Because XML 1.1 is not forwards compatible with XML 1.0, all the deployed XML 1.0 software won't read this new XML 1.1 content. That means all the Internet Explorers, BEA WebLogic Servers, XMLSpy editors, etc. etc. can't read this new great content. That is a *HUGE* cost. This is also why I'm peeved that they called XML "1.1" rather than "2.0".
What to Do
If a customer wants forwards compatibility, they have to lobby for it. And they have to do it in 2 particular ways: 1) Demand that V1.0 have provisions for forwards-compatibility; 2) Accept that V1.0 will take longer to develop with forwards-compat in mind compared to no forwards-compat.
It seems to me that the customers have generally made their choice: They want the V1.0 features as fast as possible, and they don't want to wait. This is why so few languages are built in a forwards-compat mode. If there was demand, it would be supplied. If customers, users etc. had demanded that XML 1.0 allowed for future unknown name characters, then XML 1.0 could have provided that forwards compat in a later timeframe. It certainly wasn't a shocking surprise or lightning bolt from the blue for the XML 1.0 authors...
The choice is in the customers hands, and hopefully they know the trade-offs.
