I wonder if you're fine with const, constexpr and volatile also being things. I mean, "const" really doesn't mean what one would naively think (that's what "constexpr" is actually for) and the semantics of "volatile" are also widely misunderstood.
const int a = 10; // Just an immutable variable named a
constexpr int b = 20; // Still an immutable variable named b
static constinit int c = 30; // Now it isn't even immutable
Volatile is a mess because what you actually want are the volatile intrinsics, indeed you might want more (or fewer) depending on the target. If your target can do single bit hardware writes it'd be nice to provide an intrinsic for that, rather than hoping you can write in code REG |= 0x40 and have that write a single bit... which on platforms which do not have this single bit write feature that's going to compile to an unsynchronized read-modify-write which may cause problems. However instead of having intrinsics C's volatile was hacked into the type system instead and C++ tries to keep that.
I thought constexpr was a hard physical constant, but in reality it's a weird hybrid
this visualisation helped me to wrap my head around it - https://vectree.io/c/c-constness-and-evaluation-qualifiers
And yeah, it would probably be nice to also have some sane intrinsics to provide memory_order_consume semantics... but what can you do.
But seriously, it is interesting how C++ is completely abandoning the concept. My handwavy understanding is that on some more specialized hardware acquire is substantially more expensive than consume.
ldr x8, [x8] # load a pointer from memory
ldr x1, 16[x8] # load a field through that pointer
[0] https://preshing.com/20140709/the-purpose-of-memory_order_co...