The ability for an application (eg, Office) to install side-by-side with other versions of itself is entirely different than its Backwards Compatibility (eg: ability for current versions to open and/or save Office 2007 format). In fact, because of the latter, provided they did a good job at it, the former is arguably irrelevant.
I'm not familiar with Office/Outlook/Access's APIs and their history of backwards compatibility, but given that Microsoft usually does a good job with BC, I'd tend to suspect the other vendors (IP phone/ERP software) are at fault. In my experience, there's a good chance the only real incompatibility is with the vendor's installer or some version check that prevents it from working, as opposed to really not actually working, say, because Microsoft removed some API they used.
The rest of what you're talking about really points to some other disfunction, or bad or unlucky decision.
Did you buy an IP phone system expecting 20 years of use from it? Why can't you get updates -- is it because you don't want to pay for maintenance, or did they go out of business?
The cascade effect you're talking about here though highlights something else: So many companies do things they think are saving money, but actually cost them more.
For example, they can't go to the latest IP phone software, because they need to buy a hardware upgrade that will cost $x, so it means they have to use old version of Access that uses old MySQL which means other development team spends $y extra working with that version (or paying for custom dev for other products to work with it, etc). Did anyone actually evaluate which is larger? The decision to "save" $20k on a phone system upgrade could easily cost $50k or more for several months of a developer's time.
I am still somewhat surprised that Windows doesn't have a Docker-esque sandboxing system to solve this problem (I mean, it has Docker, but it's based on a full VM). I suppose in the third-party realm at the very least you have Sandboxie, but meh...
Starting with Office 2016 (maybe 2013) App-V from MS does precisely what you describe and it doesn't require any sort of classic virtualization component to be accessibly by the OS or hardware.
See: https://en.wikipedia.org/wiki/Microsoft_App-V
The tech is there. Usage is a different story.
I'd rather have planned deprecation and make choices to (at some point) abandon certain APIs, features and formats. In the case of formats, a public release of some parser code would be nice, so that if someone really wants to get some old data, they can, but other than that, stagnation isn't as good as people make it out to be.
Some things don't need intensive maintenance, and it's a bad thing to force it for unnecessary reasons. Backwards compatibility can often be understood as 10 vendor engineers performing maintenance effort so 10,000 customer engineers don't have to. It's a massive productivity win for society.
I'm a software engineer. I hate working on ancient codebases as much as the next guy, and I personally benefit from the constant make-work of re-engineering. But, as a customer, I'd rather invest my time and money to solve new problems, rather than spend it re-solving old problems.
The code and APIs will never be "perfect," and many processes change little.
Also, it's a little ambiguous who's code you're talking about: the customer's or the platform's? If a platform that maintains backwards-compatibility is an achievement worth celebrating, because it saves loads of effort across society and give people access to software who might not otherwise be able to afford it. If a platform breaks its customer's code because it's chasing after API perfection, it's kinda abusing its customers.
The theory that a platform as 'backwards compatibility' is only good for lazy developers and lost source code. And yes, not doing maintenance saves time, but so does not upgrading your platform. I mean, if 8 inch floppies work for nuclear installations, OS/2 works for subway passenger systems, and Windows 3.1 for radio servers and other flight control systems, might as well not maintain anything at all. Heck, why not use relay logic in the subway control rooms.
I think the issue here is that you're viewing this as too all-or-nothing. If the OS/2 subway software is well-tested and does everything it needs to do, what's the benefit of spending $10 million rewriting it or paying a guy to keep up with platform changes? If IBM (or whoever owns it now) keeps maintaining OS/2 so the software can run with little to no modifications on new hardware (since hardware fails), good on them. There's probably 1,000 such systems, and that's $10 billion in savings for society.
That doesn't mean no software should actively be maintained, a lot of it should. It also doesn't mean that working old systems shouldn't sometimes be replaced or upgraded. But it does mean backwards compatibility is important and shouldn't be dismissed.
As for "...means it hasn't been maintained for 20 years..." - the OS did maintain the old API's and the way they behave to make sure old software that uses said APIs still works on new OS. Does not mean that the new APIs were not developed.
https://www.microsoft.com/en-us/download/details.aspx?id=542...
Cheap bullshit, not technical limitation, is at the heart of this level of "compatibility" issues.
Windows can run the previous version of Office. But running the current version, alongside say, Office 2007, is a major pain in the ass.
Maybe you just need to run the old version of Outlook, because your IP phone system or ERP software has some plug-in that was never written for the next version and isn't compatible.
Maybe you need to run a version of Access that's so stinking old that you have to use Windows XP in a VM.
Now, to make things worse, the database connectors for that version of Access are so outdated, that it's holding the entire company back on MySQL 5.5 because if you upgraded, your Access application wouldn't work anymore.
Not to mention, all that code you wrote 20 years ago in VBA is insecure as all hell. Unencrypted connections, ripe for SQL injection, plus that version of Access can't work with large datasets or return large results. Dammit!