Proposed resolution:

This wording is relative to N4810.

1. Change [container.node.overview], exposition-only class template node-handle synopsis, as indicated:

   template<unspecified>
   class node-handle {
   public:
     […]
   private:
     using container_node_type = unspecified; // exposition only
     using ator_traits = allocator_traits<allocator_type>; // exposition only
     typename ator_traits::template rebind_traits<container_node_type>::pointer ptr_; // exposition only
     optional<allocator_type> alloc_; // exposition only
   
   public:
     […]
   };
   

[ 2020-11-09 Approved In November virtual meeting. Status changed: Tentatively Ready → WP. ]

[ 2020-05-16 Reflector discussions ]

Status to Tentatively Ready after five positive votes on the reflector.

[ 2019-03-17; Daniel comments and provides wording ]

Due to an editorial step, the previous name node_handle/node_handle has been replaced by the artificial node-handle name, so I see no longer any reason to talk about a name node_handle reservation. The provided wording therefore only takes care of the private members.

[ 2016-07 Chicago ]

Jonathan says that we need to make clear that the name node_handle is not reserved

The private members of node_handle are missing the usual "exposition only" comment. As a consequence, ptr_ and alloc_ now appear to be names defined by the library (so programs defining these names as macros before including a library header have undefined behavior).

Presumably this is unintentional and these members should be considered to be for exposition only.

It's also not clear whether the name node_handle is reserved for library usage or not; [container.node.overview]/3 says the implementation need not provide a type with this name, but doesn't seem to rule out the possibility that an implementation will choose to do so regardless.

Daniel:

A similar problem seems to exist for the exposition-only type call_wrapper from p0358r1, which exposes a private data member named fd and a typedef FD.