Relaxed atomics are still data-race free, did you mean non-atomic accesses?
In fact, the raison d'être for relaxed atomics is to permit applications to create "benign data races" [in the second sense] that aren't undefined behavior. As it turns out, though, actually specifying what semantics such a "benign data race" has is complicated, especially when you get into the realm of avoiding things like out-of-thin-air behavior (or, to reference a paper that crossed my desk a month ago, undefined behavior executed only if out-of-thin-air happens).
It's not funny game. It's part of abstraction hierarchy and physical computing model vs. programming language computing model.
It's only funny because one would presume that there ever was a time the hardware was not playing "funny" game.
And no, it always has a giant abstraction gap between hierarchy, and that's a fundamental part of modern electronic computing. One shall allow oneself to learn those and get used to how things are actually working.
Multithreaded--really, multiprocessor--memory models are really, really confusing. Hardware memory models are generally described in terms of what reorderings are possible (e.g., loads may be ordered before subsequent stores), which is easy to understand from a hardware perspective but less easy to deal with from a language perspective. There turns out to be a wonderful theorem, though, that lets you hide all of the hardware ugliness: if you properly synchronize your code, then you can't see any of the reordering, and the compiler merely has to guarantee that the synchronization is properly handled. This is the data-race-free programming model, and it is the primary basis for all modern memory models. Stray away from this model (e.g., relaxed atomics) and you reenter the world of pain, for which no satisfactory solution has yet been found.
Discovering the pains of pointer provenance is even more recent, arguably only about a decade old. For a long time, pointer provenance has been handwaved on a vague data-dependency basis (you see this in LLVM's LangRef, for example). Unfortunately, it turns out that data dependencies are not generally preserved by compilers (this also doomed the release/consume aspect of the C/C++ memory model). An escaping/lifetime-based pointer model is closer to the actual one used by compilers, but there remains tricky things about things like memcpy [1].
It turns out there are two things that make pointer provenance painful: integer-to-pointer (where does the provenance come from?), and memory (since this usually ends up creating implicit integer-to-pointer casts in most putative models that you really want to avoid). The lesson we know from pointer provenance is that pointers are not integers, and cannot be losslessly roundtripped via integers, and Rust being newer and with a heavier emphasis on safety gives it a better chance of adopting a model here that more forcefully breaks this mistaken link.
[1] One consequence is that most formal pointer provenance models actually don't let you legally write memcpy in C code.