In addition to the other excellent answers, sometimes the addition of caches could cause incompatibility.
The 68010 had a single instruction cache that couldn't really cause any problems. The 020 increased this to 256 bytes, and later CPUs had both instruction and data caches which were even larger.
The main fault encountered with instruction caches is with self-modifying code. This is where the program re-writes part of itself. This was a common technique in the 80s. It could be used to make copy protection harder to crack (because any code dump might not reflect the code being executed, and I believe Rob Northern Copylock used that technique), or for performance reasons with data stored in the op-codes of instructions with immediate operands.
With the 020 and above changes to code in RAM that was also in the cache would not cause the cache to be updated or purged. This was an issue for some Amiga and Atari ST software.
A related but less common issue is where data in the data cache does not reflect data written to RAM via DMA. Most systems avoided this by disabling the data cache for memory that could be accessed by DMA, such as chip RAM on the Amiga.
One Amiga specific issue was that on CPUs without cache or extra memory the operation of the blitter (an memory manipulation chip primarily used for graphics) could block the CPU entire so that no instructions were executed until the programmed blitter operation was finished, due to the CPU not receiving any memory access cycles. With the addition of an instruction cache the CPU could carry on executing instructions, for example re-programming the blitter mid operation.
Beyond caches, due to architectural improvements and higher clock frequencies software on later parts would run faster, which could interfere with timing in badly programmed software. That was the reason for the "turbo" button on PCs of the era.