Proposed resolution:

This wording is relative to N4928.

1. Modify [version.syn], header <version> synopsis, as indicated and replace the placeholder YYYYMM by the year and month of adoption of P2652R0:

   […]
   #define __cpp_lib_algorithm_iterator_requirements  202207L
     // also in <algorithm>, <numeric>, <memory>
   #define __cpp_lib_allocate_at_least                202106YYYYMML // also in <memory>
   #define __cpp_lib_allocator_traits_is_always_equal 201411L
     // also in […]
   […]
   

[ 2023-06-17 Approved at June 2023 meeting in Varna. Status changed: Voting → WP. ]

[ 2023-03-22; Reflector poll ]

Set status to Tentatively Ready after seven votes in favour during reflector poll. But "if we don’t get the editors to do it for C++23 there doesn’t seem to be any point doing it."

In Issaquah, we just adopted P2652R0, forbidding user specialization of allocator_traits.

It looks like we did not deem that worthy of a feature macro.

However, it also changed the interface of the C++23 addition, allocate_at_least, which is covered by the macro __cpp_lib_allocate_at_least.

I believe we should have updated that macro for this significant change in how that function is accessed (from free function to a member of allocator_traits). Unfortunately, there are no more meetings to process a comment to that effect, and I suspect this rises beyond the purview of an editorial change, although I live in hope (as the original paper left the value of the macro to the editor, although we approved existing working papers where that macro does have a value, i.e., status quo).