Backward compatibility - damn if you do, damn if you don't

My blog entry When Sofware matures you need to cut development to stay profitable, isn't it? stirred more feedback than the elaborate comment from Nathan and Phil. So there are much more thought to share when looking at backward compatibility. In his famous 2004 article How Microsoft lost the API war Joel Spolski explained using Microsoft as example how two camps, which he labeled The Raymond Chen Camp and  The MSDN Magazine Camp are at odds with each other regarding backwards compatibility. Go read the entry, I'll wait for you. Joel and Nathan rightly point out, that backward compatibility is often taken for granted and is increasingly expensive (Apple worked around that using Rosetta, but from a way smaller base).
So what happens if you don't pay attention to backwards compatibility: customers will be very reluctant to upgrade since applications (especially custom applications) need to be upgraded and your version upgrades become a mayor exercise that gets cut once a customer hits rough water. In the end your speed of innovation slows down and you need to support a lot of old versions. What happens if you do: Nathan outlined that already.
So damn if you do, damn if you don't!
As the going joke goes: "God would not have been able to create the world in seven days if there would have been an installed base to take care of". The biggest challenge I see is the incredible creativity how platform APIs are used (and undocumented functions are handed from developer to developer as secret tip - you are lame if your program doesn't use any) and abused. Part of my job is to look at existing applications and I've seen a lot of code that made me cry (and laugh: like the Chinese application where everything was Chinese including field names and LotusScript variable names - yes you can do that in LotusScript). So what's the way out? Eventually we need to borrow a page from Wiliam Goldman. In his novel The Princess Bride he retells an abridged version of an older story, "just the good parts". So how would that look like for software:

• Make upgrade management part of the software. For Domino it is a joke that updates and patches need to be downloaded manually and distributed manually. The Linux packet managers solved that problem. I would expect a page in Domino admin to allow to do that. Eclipse update can update clients automagically, so we could use that
• Provide analysis tools. Teamstudio has the Upgrade Filters, but they don't go far enough. Well behaved code usually doesn't pose a problem when upgrading, the code I've seen will (think fragile). For browser JavaScript there is JSLint (its original tag line was JSLint will hurt your feelings), for Java there is Lint4J and Crap4J. We need such a tool for LotusScript, so overuse of client events, unencapsulated OS calls and missing Option Declare statements don't go unpunished anymore (because you can do something doesn't mean you should. Don't believe me? Try to poke yourself in the eye - you can do that). So where's the LSLint and the @Lint?
• A upgrade pilot would show functionality that is depricated in this version and will be gone in the next. It would make a nice RTC plug-in.
• A data conversion sandbox. If data in an older format is found it is put into the sandbox and can only graduate after update
• ... insert more witty ideas here ...

I'd really like to see the lints.