Proposed resolution:

This wording is relative to N5032.

1. Modify [atomics.general] as indicated:

   -1- Subclause [atomics] describes components for fine-grained atomic access. This access is provided via operations on atomic objects.

   -?- [Note ?: Although some specializations of `atomic` and `atomic_ref` are specified as explicit or partial specializations, the implementation can merge these specializations in an unspecified way, because a program-defined specialization is invalid. — end note]

2. Modify [atomics.ref.generic.general] as indicated:

   -5- The program is ill-formed if `is_always_lock_free` is `false` and is_volatile_v<T> is `true`.

   -?- The program is ill-formed, no diagnostic required, if it declares an explicit or partial specialization of `atomic_ref`.

3. Modify [atomics.types.generic.general] as indicated:

   -1- The template argument for `T` shall meet the Cpp17CopyConstructible and Cpp17CopyAssignable requirements. The program is ill-formed if any of

   […]

   is `false`.

   -?- The program is ill-formed, no diagnostic required, if it declares an explicit or partial specialization of `atomic`.

Currently, specializations of `std::atomic` and `std::atomic_ref` for non-`bool` integer types, floating-point types, and pointer types are specified as if they're full specializations. However, implementations generally merge these specializations in quite arbitrary ways.

As for 2026-04:

• MSVC STL provides all atomic and atomic_ref specializations in primary templates.

• libc++ merges specializations for integer types with the atomic primary template, and provides atomic_ref specializations for arithmetic types in many partial specializations.

• libstdc++ provides all atomic_ref specializations in the primary template, while providing atomic full specializations like the standard wording.

The divergence among implementations and standard wording is observable if it's allowed to specialize `atomic` or `atomic_ref`. Also, it's already noted in cplusplus/draft#7556 that it's unimplementable to provide full specializations for all atomic_ref<pointer-type>.

On the other hand, it's desired that `_Atomic(T)` behaves as consistently as possible in C and C++ (per [stdatomic.h.syn]/4). This is possible unachievable if atomic<T> is a program-defined specialization.

Given it's unclear whether program-defined specializations of `atomic` and `atomic_ref` make sense, and there're some potential drawbacks allowing them, perhaps it would be better to disallow specializing `atomic` and `atomic_ref`.