However to be 100% sure of what can be considered safe, it needs to be the same regardless of what hardware is being targeted.

That is how C got its UB in first place, WG14 didn't want to rule out any kind of hardware that was possible to target so UB it was.

Other memory safe systems programming languages have gone through other path and were willing to add abstractions to their runtimes instead, ensuring that the memory model remains consistent to the developers.

Naturally in languages that want to be zero cost abstraction, that solution is not welcomed.

C, C++, etc. don't even have implementations of their abstract machines. They don't have one existing as a goal. And they are happy to make certain operations exhibit undefined behavior even if that implies that it would make an implementation of the abstract machine that traps impossible.

This is why even if you were to combine valgrind with address sanitizer, memory sanitizer, thread sanitizer, undefined-behavior-sanitizer, and other existing C and C++ tools, there is still a lot of classes of undefined behavior that these tools can't detect.

That's fine in C and C++, but not fine in Rust. In Rust, if we add a new type of undefined behavior, the constraint is that it should be (demonstrably) possible to extend miri to detect it, such that if a user doesn't know whether some program exhibits undefined behavior for some inputs, they can just run it under miri, and miri will precisely pinpoint which part of their code exhibited undefined behavior and why, and how their program execution got there.

https://doc.rust-lang.org/reference/behavior-considered-unde...