[atomics.order] p1 says in the table that
Element Meaning memory_order_acq_rel the operation has both acquire and release semantics
To my naked eye, that seems to imply that even an atomic read has both acquire and release semantics.
Then, p1 says in the table:
Element Meaning memory_order_seq_cst the operation has both acquire and release semantics, and, in addition, has sequentially-consistent operation ordering
So that seems to be "the same thing" as memory_order_acq_rel, with additional constraints.
I'm then reading p2, where it says:
The memory_order_seq_cst operations that load a value are acquire operations on the affected locations. The memory_order_seq_cst operations that store a value are release operations on the affected locations.
That seems to imply that atomic reads only have acquire semantics. If that is intended, does this also apply to memory_order_acq_rel and the individual load/store operations as well?
Also, the table in p1 contains phrases with "thus" that seem to indicate consequences of normative wording in [intro.multithread]. That shouldn't be in normative text, for the fear of redundant or inconsistent specification with the other normative text.
Double-check [atomics.types.operations] that each operation clearly says whether it's a load or a store operation, or both. (It could be clearer, IMO. Solution not in current proposed resolution.)
[atomics.order] p2: What's a "consistent execution"? It's not defined in [intro.multithread], it's just used in notes there.
And why does [atomics.types.operations] p9 for "load" say:
Requires: The order argument shall not be memory_order_acquire nor memory_order_acq_rel.
(Since this is exactly the same restriction as for "store", it seems to be a typo.)
And then: [atomics.types.operations] p12:
These operations are read-modify-write operations in the sense of the "synchronizes with" definition ([intro.multithread]), so both such an operation and the evaluation that produced the input value synchronize with any evaluation that reads the updated value.
This is redundant with [intro.multithread], see above for the reasoning.