Proposed resolution:

This wording is relative to N4950.

1. Add the new paragraph after [flat.map.defn] p1 and [flat.multimap.defn] p1 (twice):

   [Drafting note: The intent is to keep the property that key/mapped types, key/mapped containers, and the comparator type are not the associated types of these nested classes during ADL. ]

   -?- Implementations may define member types containers and value_compare as nested classes of another templated class and introduce them as typedef-names. Implementations shall ensure that these nested classes are not themselves class templates and have the specified names.

[ 2023-11-02; Reflector poll ]

Set priority to 3 after reflector poll. "This would mean we have to care about whether the template parameters are associated entities of the containers type, for ADL purposes." "That only matters if you're doing silly things, we shouldn't design the library with silly people in mind." "Nobody asked to be able to do this for value_compare in associative containers, why do we think vendors would take advantage of this freedom here? NAD."

Per current wording, std::flat_map<K, V, C1, KCont, VCont>::containers and std::flat_multimap<K, V, C2, KCont, VCont>::containers need to be different types since they are specified as nested classes. Likewise, std::flat_map<K, V, C, KCont1, VCont1>::value_compare and std::flat_multimap<K, V, C, KCont2, VCont2>::value_compare also need to be different types.

It may be better to allow implementations to make different std::flat_map/std::flat_multimap specializations share same nested classes.