I’m but a mere mortal but as an outside observer of rust and from my playing around with it, doesn’t the borrow checker currently handle this for you? Ie part of fearless concurrency?
(This is handwavy and imprecise, but it's the easiest way I can explain it.)
However if you start manipulating atomics directly, while the atomics themselves are safe the behaviour can get quite complicated below seqcst. The latest Crust of Rust is rather illuminating to the subject for people like me who had not had to really dive into the logic and implications.
Given that Rust's "shared xor mutable" is guarded with mutexes, atomics or other synchronization primitives, memory reordering can't violate Rust's memory safety guarantees (assuming the sync primitives are not buggy, of course).
But this does not guarantee that your program logic is correct if you are sloppy with memory ordering. If you do two atomic stores, they are not guaranteed to occur in that order if they use "relaxed" ordering.
This gets more complex if you're writing device drivers and communicating with peripheral devices using memory mapped i/o.
I think rust gets away because atomic ptr is a raw ptr so it can only be dereferenced in unsafe code. So in practice relaxed atomics require unsafe where it matter (which makes sense to me).
The memory model is something different: it governs how memory operations are ordered in a concurrent system. You can have a program with no memory safety issues, but nonetheless is not correct (that is, it doesn't do what you expect it to do) because you have specified the wrong memory ordering of some operations.