This is issue is not related to ordering, but to visibility (i.e., when is a memory side effect globally visible).

Many concurrent memory models (C++ at least, java very likely) allow coalescing stores to atomic variables as long as there is no other interleaving side effect; this is normally a desirable optimization.

As described by dvyukov, the go compiler seems to be aggressively coalescing all stores till the end of the loop (which never happens).

Store coalescing is desirable, but it is hard to specify completely, for example the C++ standard has non normative wording stating that stores should be visible in a reasonable amount of time exactly to prevent this sort of issues.

Java only requires that the writes can't be seen out of order - if a thread writes A then B, another thread can't read the new value of B and then the old value of A. If coalescing them makes them all happen atomically, that's fine.