This sounds very questionable because you're essentially standardizing
one form of synchronization, and this form isn't necessarily the best
for all purposes.

- In some cases, the user really would have just wanted a mutex
guarding the whole container.
- In other cases, the user would have wanted multiple mutexes (e.g.
one mutex per N buckets in a std::unordered_map)
- In other cases, a mutex per node in some graph/linked list is desirable.
- In other cases, lock-free data structures are best.

You're basically setting any one of these implementation choices in
stone; they can't really be altered due to ABI compatibility.

I could certainly see new research or new hardware instructions become
available which demonstrates how to implement more things lock-free,
or implement them lock-free more easily.

The standard doesn't have the flexibility to benefit from any such new
findings, so it's the worst possible place to define these thread-safe
data structures. They belong in third-party libraries.