Does it require Blink to completely replace WTF::HashMap in the code base with flat_map? (which is not realistic because WTF::HashMap is integrated with Blink GC's infrastructure)

No definitely not, just generated Mojo bindings in Blink would use flat_map
wherever mojom maps are needed.

Thanks. Then who is responsible for converting the flat_map to WTF::HashMap when the mojo message is passed to Blink?

If the conversion is encapsulated in the auto-generated mojo bindings, I'm happy with it :)

Sorry, the issue is specifically when someone wants to use a mojom map
where a (non-typemapped) mojom struct is the key type. If we generate code
which uses HashMap to represent the map, then we must also generate hashing
code for every mojom struct (we can't know at generation time whether or
not any given struct will definitely be used as a map key somewhere, so
we'd have to generate it just in case).

The point of the blocked bug is that we would like to stop generating
hashing code altogether, so that would mean never generating code which
uses HashMap in these cases. And for consistency I think that would in turn
mean never generating code which uses HashMap for any cases.

This would mean callers who want to pass a HashMap to a mojom call in blink
would have to explicitly convert, and implementations of mojom interfaces
would receive a flat_map and have to manually convert to HashMap.

How would that conversion code look like? If it's just one helper function, I think it will be acceptable.