https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
--- Comment #5 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> --- > I think this also means the standard transparent-compare overload is > underconstrained [...] m[k] for volatile k is a soft/constraint error if the comparator is non-transparent, but is a hard error if the comparator is transparent. Naturally one would expect m[k] to behave consistently regardless of comparator transparency, so the current behavior seems like a wording defect. It's not clear whether the solution is to uniformly accept, or reject, volatile k. FWIW, I think I agree (at least I don't disagree) with your analysis; but I still think there's a fairly obvious fix to be made to libstdc++, which is to give the helper an uglified name and make all three operator[] overloads call it. That makes everything Just Work in the most obvious way, right? In particular, that will make Rufei's `m[e]` work with exactly the same degree of success as `m.try_emplace(e, 0)`: libstdc++'s `try_emplace` already uses the "uglified helper" approach with success. I think LWG's position on `volatile int vi` as a key is "we don't care what you do with volatile," e.g. `std::less<int>()(vi, vi)` doesn't compile either. So maybe that's an unnecessary rabbit-hole, unless there's a way to do the same kind of thing without involving the `volatile` keyword. Now, I don't fully understand why std::flat_map should behave any differently from std::map or std::unordered_map in this respect. Is it that map and unordered_map *do* have these same issues in C++26, but we can't see them yet because nobody's implemented C++26 P2363 "Extending associative containers with the remaining heterogeneous overloads" for those containers yet? We *don't* see a similar issue with C++14 N3657 "Adding heterogeneous comparison lookup to associative containers," but I believe that's because everything in *that* paper (find, count, equal_range, etc) takes `const K2&` instead of `K2&&`. `const K2&` doesn't have the same issues as perfect-forwarding `K2&&`.
