Proposed resolution:

This wording is relative to N4988.

1. Modify [container.node.overview] as indicated:

   […]

   -4- If a user-defined specialization of pair exists for pair<const Key, T> or pair<Key, T>, where Key is the container's key_type and T is the container's mapped_type, the behavior of operations involving node handles is undefined.

   -?- For each node handle type NH and any type A, uses_allocator<NH, A> meets the Cpp17BinaryTypeTrait requirements ([meta.rqmts]) and its base characteristic is false_type.

[ 2024-10-09; Adjust wording as requested in reflector poll ]

[ 2024-10-09; Reflector poll ]

Set priority to 3 after reflector poll.

"Strike the carve outs for program-defined specializations." If it's broken for uses_allocator<NH, A> to be true when `NH` is not a program-defined type, then we don't want to allow users to make it true for a program-defined `A`, that would still be broken.

Currently, node handle types ([container.node]) have the member allocator_type type alias, which makes std::uses_allocator report true for them. However, they don't have allocator-extended constructors, and it's unclear to me whether it's better to make them have such constructors.

The status quo renders the following seemingly reasonable program ill-formed.

#include <set>
#include <map>

int main() {
  std::pmr::set<int> s{1};
  std::pmr::map<int, decltype(s)::node_type> m;
  m.emplace(1, s.extract(1));
}

Perhaps we should consistently treat node handles not uses-allocator-constructible.