In srfi-125, the seventh paragraph of Specification section refers to eq-comparator, eqv-comparator and equal-comparator, which was relevant with srfi-114 but no longer so with srfi-128.
"[T]his means that mutating a key in a hash table based on eq-comparator or eqv-comparator, or the equality predicates eq? or eqv?, may be possible, but mutating a key in a hash table based on equal-comparator or equal? is almost always unsafe."
Initially I thought it would be trivial to replace them with "comparator returned by make-eq-comparator" and such, but I realized it's more complicated.
Srfi-128's make-eq-comparator and make-eqv-comparator are specified to use the same hash function (default-hash) as make-equal-comparator. That means the hash function is mostly likely to recurse into lists and vectors, so mutating the key of hashtables based on the comparators returned by make-eq-comparator / make-eqv-comparator can be said unsafe, too.
I actually overlooked that during srfi-128 discussion. Was there a reason for make-eq[v]-comparator using default-hash? It might be inefficient if I only want to hash with object identity for eq-hashtable.