Hi,

On 07/06/2026 11:43, Rainer Deyke via Std-Proposals wrote:
> It's a concern if those 3rd party containers want to implement the
> Associative Container Named Requirements, and be used in a generic
> context that requires the Associative Container Named Requirements.

Well, sticking with today's requirements, you have a perfect viable and
portable way of expressing such generic code, with several examples
earlier in the thread -- basically a one liner that converts the pair
returned by `equal_range` in a `subrange`.

You're right that this could be done in a more convenient/expressive
way, but still there's no real blocker for you to write generic code?

> Either the new function is added to the Named Requirements (meaning that
> existing containers no longer meet the Requirements) or it is not
> (meaning that generic code cannot use this function).

Existing container no longer meeting the requirements is not a blocker
for the evolution of the Standard Library. As a somehow recent
precedent, `insert_range` was added to the requirements in the C++23
cycle, making existing 3rd party containers non-conforming until they
incorporated that change. So there's no problem in principle at adding a
new named requirement for an imaginary `equal_subrange` that returns a
`ranges::subrange`.

My 2 c,
--
Giuseppe D'Angelo