Proposed resolution:

This wording is relative to N5014.

1. Modify [atomics.refs.ops], as indicated:

   static constexpr size_t required_alignment;
   

   -1- The alignment required for an object to be referenced by an atomic reference, which is at least `alignof(T)`. The value of required_alignment is the same as atomic_ref<remove_cv_t<T>>::required_alignment

   -2- [Note 1: Hardware could require an object referenced by an `atomic_ref` to have stricter alignment ([basic.align]) than other objects of type `T`. Further, whether operations on an `atomic_ref` are lock-free could depend on the alignment of the referenced object. For example, lock-free operations on std::complex<double> could be supported only if aligned to `2*alignof(double)`. — end note]

When p3323r1 fixed support for atomic_ref<cv T> we didn't consider that an implementation could define `required_alignment` to be different from atomic_ref<T>::required_alignment. For example, a processor could support atomic loads on any `int` object, but could require a greater alignment for atomic stores (and read-modify-write and modify-write operations). So the `required_alignment` could be `alignof(int)` for `const int` but `2 * alignof(int)` for `int`, because the latter is needed for stores.

A malicious implementation could even define `required_alignment` to be greater for the `const T` specialization, which would make it undefined to use the new converting constructor added by P3860R1.

We should constrain implementations to use the same `required_alignment` for cv `T`, so that users can use atomic_ref<const T> on any object that is referenced by a atomic_ref<T>.