No thank you.  It is perfectly reasonable to use set operations to make the implementation simple, fast, reliable, and suitable for most use cases.  Marking this as a rejected feature request.

As for documentation, I don't see any need to accommodate a pedantic reading of "mapping" in the general sense versus collections.Mapping in the formal sense.  Additional text would likely create more confusion than it solves and would likely get in the way of normal users who are just trying to learn how to use ChainMap.

If you truly feel that users need to know about every place that the  adjective "mapping" carries with it a dependency on hashability, then consider a FAQ entry or blog post on the subject.  Otherwise, we going have to replace term "mapping" with the more awkward "dict-like object".

Serhiy, while I admire your devotion to studying all the code in the standard library, it really isn't helpful to have you challenge and second guess every single design decision.  While you may have a ton of spare time to generate enormous numbers of PRs, feature requests, and bug reports, it is eating-up *all* of my development time.  It is a constant distraction from real work than needs to be done.   In particular, most of the issues seem to be "invented problems" that aren't based on any actual user need or reported problem.  Further, it risks excessive code churn, feature creep, risk of introducing new problems/incompatibilities, and destabilizes published code.  It may be fun to rewrite everything you look at, but it isn't a good practice.