> Nowadays most PCs feel like a random terminal

It's a fun perception. For the longest time, all the "serious" computers were used through networks and terminals and didn't even come with any ability to connect a monitor or a keyboard (although a serial terminal would work as the system console). I used to joke (usually looking at Unisys Windows-based big servers), if the computer had VGA and PS/2 ports, it wasn't a computer, but a toy. Those Unisys servers weren't toys, but you could run Pinball and Minesweeper directly on them, which kind of said otherwise.

I think we got used to such levels of platform bloat that we don't care if the UI toolkit these days is bigger than the entire operating system that runs 95% of the world's payment transactions.

> Also most software runs on ARM now and I don't think that has actually happened in practice.

At least in my house, ARM cores outnumber x86 cores by at least four to one. And I'm not even counting the 32-bit ARM cores in embedded devices.

There is a lot of space for memory ordering bugs to manifest in all those devices.

It's definitely a real issue in real code, since the CPU isn't bound by things like function boundaries or alias analysis or pointer validity. For example:

  x = *a;
  if (x) y = *b;

The compiler cannot reorder the load of b before the load of a, because it may not be a valid pointer if x is false. But the CPU is free to speculate long ahead, and if the pointer in b isn't valid, that's fine, the CPU can attempt a speculative load and fail.

It's not particularly common and code that has this issue will probably crash only rarely, but it's not too hard to do.

If it's programmed in assembly, it just wont compile for a different architecture.

The issue is that the C memory model allows more behaviours than the memory model of x86-64 processors. You can thus write code which is incorrect according to the C language specification but will happen to work on x86-64 processors. Moving to arm64 (with its weaker memory model than x86-64) will then reveal the latent bug in your program.

  *a = 1;
  *b = 'p';

  *a = 1;
  *b = 2;

OpenBSD famously keeps a lot of esoteric platforms around, because running the same code on multiple architectures reveal a lot of bugs. At least that was one of the arguments previously.

The compiler relies on the language and programmer to enforce and follow a memory consistency model

What is "correct"? If you write code that stores two values and the compiler emits two stores, that's correct. If the programmer has judged that the order of those stores is important, the compiler may not have any obligation to agree with the programmer. And even if it does, the compiler is likely only obligated to ensure the ordering as seen by the current thread, so two plain load instructions in the proper order would be enough to be "correct." But if the programmer is relying on those stores being seen in a particular order by other threads, then there's a problem.

Compilers can only be relied on to emit code that's correct in terms of the language spec, not the programmer's intent.

You don't need to be writing assembly. Anything sharing memory between multiple threads could have bugs with ARM's memory model, even if written in C, C++, etc.

Not even close. Except maybe in Rust /s