As CPU's evolve sometimes some code will break, though usually not much. Then there are the decisions to completely break backwards compatibility to the point of not being the same ISA, these are times when thought to the past should be given. This has happened a few times on a few systems, not only do to the CPU, though also in some cases do to severe changes in the OS. Part of the issue is the number of people that think in the limited way of *nix systems (eg System V, BSD, Minix, Linux, NeXTSTEP, etc), these people see a world where they would like all code to be independent of the CPU or other HW details (though they still hold the dogma of 'the OS must be Unix like' in high regard, thus limiting portability).

In the world of Desktop Computing OS's backwards binary compatibility is important. There are large volumes of software that has not been updated for decades and is perfectly safe in nature and still very useful, this do to the nature of personal Desktop Computing.

When a CPU is updated in a way that breaks a bit of backwards compatibility there are usually methods to run old software still near native on the updated CPU, in other cases the CPU has some means of supporting the old code. This is true for changes like Harvard Cache, extending the Program Counter to be the full word size of the CPU, etc. These changes improve the experience of users and programmers so are worthwhile to see implemented.

Now days there is a trend to implement a radically new ISA and call it a wider version of the CPU previously provided by the same company. If the ISA is radically new then it is not the same CPU, a couple of decades ago any company would have called the design a different line of CPU. In some cases there are still means of supporting the older ISA code, though this is becoming less common as well.

.