@Amirography@cjk I think SPJ's perspective on this will probably have changed a bit. In this talk, he's basically reflecting on the early history of Haskell, and it's certainly been one of the principles of Haskell evolution not to get dragged into maintaining compatibility too early.
I think there's much more emphasis on stability now. The Haskell Foundation has a Stability Working Group. For user-facing changes to GHC, there is a clear GHC proposals process that has to be adhered to. Nevertheless, there are still ongoing problems: one of the main problems is that the base package, which provides many of the most fundamental functions, is locked to GHC, so if you upgrade GHC, you have to upgrade base. Other libraries then depend on certain versions of base and are incompatible with others. This can lead to scenarios where a security fix in one package you need goes along with a dependency on a later base, which then means you have to upgrade GHC, which then means you have to make other changes. This sort of stuff isn't great. It's also not trivial to fix, although it's clearly identified as a problem, and people are working on improving this over time.
Another potentially annoying problem is that lots of things are sensitive to compiler versions (also tooling such as HLS). This is unlikely to be solved ever, but can be worked around by other tooling such as Nix relatively effectively. But the underlying point is that GHC has an aggressive optimiser including all sorts of cross-module optimisations, and that means that internal formats change essentially all the time.
jaror