No reason at all, then. Because I am manually dealing with alignment in my code.

Wrote a lisp, its bytes type supports reading and writing integers at arbitrary locations within the buffer. Test suite exercises aligned and unaligned memory access for every C integer type. Also wrote my own mem* functions, dealing with alignment requirements in those was certainly a fun exercise.

Yeah, the unaligned accesses aren't going to be atomic unless the hardware supports it.

> And in that time, the value of one of the two addresses that the hardware has to load can change.

You mean volatile addresses that could spontaneously change in the middle of the reads? Like memory mapped I/O addresses?

I would expect these to have stricter access requirements than arbitrary general purpose memory locations.

> I would hope you're not so stupid as to design hardware that relies on this

You and me both.

> And if you do that, there is nothing that the compiler or the standard can do. It can't be done correctly

Anything that does that is broken and terrible anyway. It really shouldn't contaminate language design. It's the sort of thing that compilers should be adding attributes for, rather than constraining the language to the point nothing works correctly and making us use attributes on everything to restore some sane baseline behavior.