To the list of four options I suggested for bidict, you can add one more.  Create a feature request for a C implementation of collections.abc.KeyView. ISTM that your core issue is that bidict won't use the intended and guaranteed solution because the KeysView ABC is thought to be too slow (you should test this -- the `yield from self._mapping` code is very fast).


> .mapping attribute in Python 3.10+ now leaking internal state.

We do not agree on this essential point.  The "leak", as in "all abstractions are leaky", is in the bidict code, not in the dict_keys code.  The .mapping attribute itself is accurately refers to its underlying mapping.

This is consistent with how other wrappers provide a __wrapped__ attribute (or __fget__, __func__, func, maps, etc).  If some class ever uses an lru_cache, cache, property, boundmethod, partial object, or chainmap, then it is possible for the user to unwrap one level of abstraction.


> Now suppose a new .mapping attribute were added to dict_keyiterator objects in a future version of Python

We don't do that for iterator objects.  If we did, then ChainMap would have the same options as bidict has.  Most likely, we would leave it as an undocumented, non-guaranteed implementation detail (much like random.randrange is a bound method with a __func__ attribute rather than an actual function).

If we thought users really cared about the exact object returned and its full API, then we would have several options:
1) Document that that aspect of the API is non-guaranteed,
2) Document that that aspect is guaranteed.  This would lock in our design choice forever, but all allow users the opportunity to exploit the new capability.
3) Wrap the iterator to hide parts of the API we don't want to expose.  For example, return `chain(d)` instead of `iter(d)`.


> I even have the passing property-based tests to prove it

That tests an invented property that isn't true and wasn't ever intended to be true: "The API of the concrete dict_keys type is the same as the API of KeysView ABC".  The correct property is: "The API of the concrete dict_keys type implements the KeysView ABC but may do other things as well". This is the common and normal relationship between ABCs and concrete classes.  It is no more surprising that Mapping not supporting __or__ while dict does.


> I also have counterpoints for your other feedback,

I fear that we have an asymmetry of time available to explore every possible nuance including the counterfactual you gave in the last post.  Doing so eats heavily into my limited time available for development.

I don't think there is more that can be done here.  We already have an official and supported API for your purpose. The dict_keys concrete API is unlikely to ever be built-out as a general purpose optimization of the KeysView ABC (that violates a number of design principles regarding separation of concerns, tight coupling, premature optimization, and the proper relationship between concrete and abstract classes).

Please consider using one of the four options (now up to five) that I suggested previously.