Proposed resolution:

This wording is relative to N5014.

1. Modify [tuple.cnstr] as indicated:

   template<class Alloc>
     constexpr explicit(see below)
       tuple(allocator_arg_t, const Alloc& a);
   […]
   template<class Alloc, tuple-like UTuple>
     constexpr explicit(see below)
       tuple(allocator_arg_t, const Alloc& a, UTuple&&);
   

   -32- Preconditions: `Alloc` meets the Cpp17Allocator requirements ([allocator.requirements.general]).

   -33- Effects: Equivalent to the preceding constructors except that each element of non-reference type is constructed with uses-allocator construction ([allocator.uses.construction]).

[ 2025-10-15; Jonathan provides new wording ]

I don't think we care about uses-allocator construction of references in general. You can't construct a reference using `allocator_traits::construct` nor put references in containers. For a `std::pair` containing a reference, I think `make_obj_using_allocator` and `uses_allocator_construction_args` work fine. The problem only exists in the `std::tuple` wording where we say that the elements are constructed using uses-allocator construction. So let's just fix that.

[ 2025-10-14; Reflector poll ]

Set priority to 3 after reflector poll.

"There is a defect, but the right fix is to just define uses-allocator construction of references as equivalent to normal construction."

Per [allocator.uses.construction]/1, uses-allocator construction is only defined for objects. And presumably, an attempt to construct `std::tuple` of reference from an `allocator_arg_t` constructor causes a hard error.

Since C++23/P2255R2, it seems that these `allocator_arg_t` constructors are conditionally deleted according to [tuple.cnstr]/33. However, it's confusing that these constructors are sometimes non-deleted when the tuple contains a reference, while there are hard errors in an instantiation instead.