3) Most of the functionality provided by (srfi 146 hash) is already in (srfi 125), hash tables. So if we were about to create a new SRFI that is concerned with mappings based on hashing, it should be some kind of unification of (srfi 125) and (srfi 146 hash).

I think that (srfi 146 hash) is already a superset of the non-deprecated parts of (srfi 125), with the exception of hash-table-pop!.  I think it would be good to add mapping-pop(!), which returns three values: the first key (or any old key in (srfi 146 hash), the associated value, and a mapping containing all the remaining associations.  In that way there is no need to unify, just to implement hashmappings.

If you want to keep both types in the same SRFI, I would still like to have the procedures separated by name.  Let us have mapping-* and hashmap(ping)-*, just as we have set-* and bag-* in SRFI 113.  I could have called them both sets, and just had (srfi 113) and (srfi 113 multiset), but I didn't, because I thought they were equally important concepts.  If that is done, I don't much care if they are in the same library or the same SRFI.