In Rust, safe code cannot create a situation where an &mut aliases anything else that is accessible.

Unsafe code can do so, but it makes sense to ban it and make that undefined behavior at least if the &muts are then used, since in addition to preserving the desirable safe semantics, it means that the information can be used in optimizations like alias analysis without fear of introducing bugs due to unsafe code creating and using aliased &muts.

However, current Atomic* and mutex implementations require an &mut self.

This is wrong, because the whole point of such classes is to support multiple concurrent users, so having them take an &mut self means that they are either pointless or that clients are breaking the rules about &mut detailed above.

So, I think atomics need to take &self, and AtomicT should simply be viewed as a variant of Cell that uses atomic operations instead of non-atomic ones.

This also applies to operations on mutexes and other lockless data structures.

Note that this means that safe code will be able use atomics (for example, by putting them in an Arc-like structure without a Freeze bound), which does introduce potential data races but not memory corruption; however, data races that can happen due to multiple atomics can be equivalently produced using multiple RwArcs, so I think this is not an issue.

There has already been quite some discussion of this in pull request #11520, and also a partial implementation (it doesn't change the compiler intrinsics themselves, only the high-level Atomic* APIs).