Well, this is something not really present with little older, 8-bit computers - for instance OS was not changed at all in case of Sinclair Spectrum original v. , what was manufactured over some 7 years. The reason was for sure that OS on 8 bitters was much simpler, shorter, and of course it made them easier for coding, predict all possible situations, etc.
Atari ST was designed with much more functions, SW types supported, displays usable, storage types and so on ... , as 8-bit home computers. Plus, there was using of GUI (graphical user interface) at basic (starting) screen for most common functions - browsing disks, starting SW, doing some copy, transfer operations and so on ... Even listing what much more can do with it needs plenty of space.
So, it was needed to do TOS updates during time, to make it work better. And yes, it was better in later versions in many situations. Sure, not only Atari did so in that time, it was usual with all more complex computers, OS.
But, as with all good intentions it may have some bad side effects (not sure that it is good to call it so) - maybe SW authors should be more cooperative and do some new versions of their SW too . Happened only in rare cases. And there were other things, factors which made problems - lack of all possible RAM in programmers computers, not enough testing, not enough detailed DOCs from Atari ...
So let's see most common Atari ST TOS version related SW running problems:
Game (SW) runs well under TOS 1.00 but not with later versions. Mostly, the reason is to use in SW some specific addresses and/or function parameters present in TOS 1.00, which are not declared as some system variables, addresses - they are just result of coding, compiling. And even differ in different language versions. As extreme example I know GFA Artist - it is German program, and works only in German TOS 1.00 . Why ? - They used some direct calls in TOS address space - which have different address in even different lang. versions.
OK, maybe did not care about other lang. versions, but what about later TOS versions ?
Well, not only address changes causing problems. But I saw (and fixed) other similar case: Tracker (Rainbird 1987) - using direct addresses of TOS 1.00 mouse reading code - they changed in later TOS versions, and even are not same in all lang. versions. Sure, it may be problem of not enough detailed TOS DOCs by Atari .I was able to fix it many years later, thanx to much more details about how TOS mouse (and other input devices) code works.
Different TOS (in ROM) start address: TOS 1.00-1.04 starts at address $FC0000, while TOS 1.06, 1.62, 2.06 starts at $E00000 . If some SW does direct read at presumed TOS start address it will cause address error crash if it is not address of TOS start in machine where running SW . Yeah, it is because SW coders were not aware about possible change of it - and it can be done better - if know details how all it works - there are system variables to see what is TOS start address. Still, do not blame only SW authors - Atari should be aware of possible problems, and warn SW authors.
This is pretty specific, and not so spread: TOS function calls (mostly Trap #1) save CPU registers D4-D7, A3-A6 - so they will be same after call ending. That helps code using them - but there are some differences even with it in TOS versions - so in earlier, like 1.00, 1.02 some of registers in range of D0-D3, maybe A0-A3 will not be different after returning of Trap call . And it is case with game Prince of Persia - good with TOS 1.00, 1.02 - not with later . It needs patch to work with 1.04 and later. What I did . Now real question is - why they did coding so ? Not having enough detailed TOS DOCs, or just it was how it worked good in their testings ? Yeah, maybe this is the essence of whole this thing - we just can not blame one side, as all it is too complex, no enough details of how it all happened then ... OK, the point is not to blame someone - the point is to learn from all it - and that would be: take care about details, do OS that handles as much situations well as possible - and that stands for all social, political situations too !
TOS 2.06 compatibility problems: this TOS v. has improved Desktop with more functions, support for HD floppies, 68010 CPU ... Because improved Desktop it uses more RAM, so starting address of SW ran is higher some 20 KB than in 1.04 - and that may be too much for some SW, especially games.
Floppy code is changed (because HD support) and it uses Timer-C for time-out detection - as it is set at boot. But if some SW changes Timer-C parameters, code for floppy read/write will fail. And it is case with many games - they use Timer-C for own purpose, with own parameters, code. I made special fix for such case, what makes floppy access working with TOS 2.06 even when Timer-C is changed from start setting .
And of course TOS v. incompatibility has influence to running SW from hard disk too. However there is something what can help for both: running from hard disk (now rather SD card) and TOS v. problems: running specific TOS version in high RAM . So, we can choose TOS v. best for that purpose, and run all what can work with it - may need some corrections, but that will be good then for all configs with diverse TOS versions - so corrections for only 1 TOS v. Sure, that needs more RAM in computer, but with hard disk run more RAM is already needed, and that plus 90-180 KB RAM is no problem - there is enough space in 1 MB for game run: 512 KB, then for saving machine state at game start (usually some 150 KB) and extra code needed for specific hard disk run operations (including state saves, hard disk aceess ...). If game needs 1 MB RAM for floppy run 2 MB RAM is needed. For very RARE games needing 2 MB RAM for floppy run 4 MB is needed - not real problem today.
Some smartheads wrote around 2009 that most of Atari ST games had direct floppy access code , and that don't use TOS function calls. And they did not make 'patching' of TOS using games at all (Klaz did some with own code for it) . Total count of such 'patches' is under 400 . I myself did over 2700 . And percentage of TOS using games is actually some 65-70% . What I knew even at 2009, when all it was relative new for me. And that was reason why I developed systems for running TOS in RAM, hard disk access during game play and other things. Will not go here in details - can see about on same pages on this site. Just this: first version was for games starting from AUTO folder PRG - then needs only GEMDOS part of TOS (about half) . Which TOS v. ? Of course 1.04 (UK) - latest v. for unmodded ST machines , and it can work well with STE machines too (in RAM) .
Count of games using AES is much lower, but there is lot of good ones - so made full TOS 1.04 in RAM too. And in latest years even 1.62 in RAM because some games needed it (really only few) .
And one more good thing too : as my adapts normally have simple exit to Desktop and state saves - activating them by simple key press - TOS in RAM helps in it too - if game using TOS for keyboard read then implementing it is really simple (with little help added to TOS in RAM) - if game uses own code for such read then need to trace it, understand how works and add some changes in game code - well, better said some hooks to achieve additional key press detections.
Good summary, Peter. Thanks! :)