I came across this thread from the old mailing list today:
https://groups.google.com/a/isocpp.org/g/std-discussion/c/YEB0sIgGoHA/m/PL4NYEq5yykJ

The claim was that std::atomic<T> has undefined behavior if T fails to meet
the requirement that it "shall be trivially copyable". Daniel Krügler
stated that [res.on.functions]/2 (I suppose of what was at the time the
C++14 draft) applied to this situation.

I've always thought that [res.on.functions] only applies to the *specific
cases* delineated in that section, which is necessary because violations of
the requirements in those specific cases are impossible to diagnose in
general. For example, the compiler cannot prove that a replacement
allocation function fails to return suitably aligned storage. A standard
library component cannot `static_assert` that it has been instantiated with
a complete type, for reasons discussed here
<https://stackoverflow.com/questions/1625105/how-to-write-is-complete-template>
.

So, my interpretation is that [res.on.functions]/2 doesn't apply to the
violation of the trivially copyable requirement for atomics. I think that
[intro.compliance]/1 controls (*i.e.*, such violation is required to be
diagnosed), as Casey Carter originally stated.

For atomics, the issue is moot in C++20 because the standard now says that
the program is ill-formed if the type is not trivially copyable. However,
as [res.on.functions] still plausibly applies to other sections of the
standard, I am still wondering what it is supposed to mean.

-- 
*Brian Bi*