The papers that I mentioned that it would be really nice to discuss here
are:

wg21.link/p0943 - This has been adopted by wg21 in November. It assumes
that we want _Atomic() and std::atomic<> to be synonymous in C++, which
really only makes sense if _Atomic() has similar semantics in C. In
particular, this gets questionable if C constrained _Atomic(T) to have the
same alignment/size as T. That issue interacts with the type qualifier vs.
specifier _Atomic issue in C. It would be nice to discuss this soon, since
this probably has implications for both C++23 and C23. (A fallback here
would be to remove _Atomic from the common subset and to limit that to
atomic_int and friends. But that would be unfortunate.)

wg21.link/p1478 - Byte-wise atomic memcpy. Much more esoteric, and less
urgent. This is on track for adoption into a C++ TS. But given that it is
C-like functionality, it would be good to understand WG14's opinion. Though
esoteric, it seems to be functionality that we're otherwise lacking, and
that many performance-sensitive systems eventually need. WG21 has
repeatedly reinvented it in different forms.

There are of course also various memory model efforts going on in a
combination of WG14 and WG21 (out-of-thin-air, memory_order_consume
replacement, pointer zap, provenance). Much of this is still exploratory at
this stage, and is probably mostly OK the way it is? It will clearly have
to affect both languages in the end, since these end up fundamentally
affecting compiler back end assumptions.

Hans