Proposed resolution:

This wording is relative to N5014.

1. Modify [allocator.uses.construction] as indicated:

   -2- The following utility functions support three conventions for passing `alloc` to a constructor:

   1. (2.1) — […]

   2. (2.2) — Otherwise, if `T` has a constructor invocable as T(allocator_argallocator_arg_t{}, alloc, args...) (leading-allocator convention), then uses-allocator construction chooses this constructor form.

   3. (2.3) — […]

[ 2025-10-14; Reflector poll ]

Set status to Tentatively Ready after five votes in favour during reflector poll.

Unless the `std::allocator_arg` tag object is not supposed to be used, wouldn't it make more sense to preserve the "if `T` has a constructor invocable as `T(allocator_arg, alloc, args...)`" wording and change every `allocator_arg_t` into const allocator_arg_t&, so that we check for construction from the const tag object, and then actually use a const value in the constructor arguments. Strongly don't care though.

Currently, [allocator.uses.construction] bullet 2.2 states:

Otherwise, if `T` has a constructor invocable as `T(allocator_arg, alloc, args...)` (leading-allocator convention), […]

However, when forming construction arguments in the utility functions, we're actually using cv-unqualified rvalue of `allocator_arg_t`, which can be inferred from using plain `allocator_arg_t` but not const allocator_arg_t& in [allocator.uses.construction] bullet 5.2.

It seems that such mismatch was present even since C++11 (per N3337 [allocator.uses.construction]/1.2). If the use of plain `allocator_arg_t` is considered correct, I think we should fix the description.