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
- 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 ...