Yes, I'm in exactly that situation (making industry specific windows desktop software) so I'm very interested in hearing about the specific issues here.
Obviously any developer can screw up and do thigs like "if !winVersion.StartsWith(...)" and there is not much microsoft can do about that, apart from naming windows 9 windows 10...
But even broken and buggy API's tend to be maintained by microsoft just because they can't test all the software floating around that depends on it. So it's usually very very hard to accidentally make a program run on Windows version N but not on Windows Version N+1
Occasionally, bugs get fixed despite programs depending on those bugs. They do not guarantee complete bug-compatibility between releases, or even within the same release - to do so would imply they could never fix a bug without writing a new function for the bugfix and persuading all developers to use the new function and release an update, then convincing everyone to use the updated software, even when there's no known software which depended on the buggy function's behaviour.
It used to be that when Microsoft found that a specific program was getting in the way of a bugfix, they'd detect the program and perform the buggy behaviour, or they'd patch the software on-the-fly. I have no idea if they still do this.
There's one game that depends on winmm callbacks being called on a separate thread because the game actually calls SuspendThread() from within the callback! During the mmdevapi move around Vista/7, MS switched to calling the callbacks from the application thread and the game now deadlocks. It does work in compatibility mode, though.
