SRFI 125 "strongly encourages" the use of SRFI 128 comparators.

The hash functions supplied by the sample implementation of SRFI 128
are extremely slow (two to three decimal orders of magnitude slower
than the corresponding hash functions of SRFI 126), and (unlike the
hash functions of SRFI 126, which have no such limitations) are "not
applicable to circular structure or to NaNs, or to objects containing
any of these."

I assumed that performance problem and those limitations would be easy
to fix, but it turns out that SRFI 128 contains a couple of absolute
requirements ("must"-ard) that interfere with efficient implementation
in general and emphatically rule out efficient implementation of hash
functions compatible with SRFI 128 that terminate on all arguments.

SRFI 128 is already final, so we can't fix it.  We can still change
SRFI 125, however.  I see four viable ways to recover from SRFI 125's
dependence upon SRFI 128:

    1.  Elaborate upon the "Implementations are permitted to ignore
        user-specified hash functions in certain circumstances"
        loophole to say implementations can ignore the user-specified
        hash function whenever the equality predicate is equal? or
        any refinement of equal?.

    2.  Recommend that all comparators be created using hash functions
        exported by SRFI 126 instead of relying upon the SRFI 128
        default-hash and all of the SRFI 128 constructors that use
        default-hash or enforce the SRFI 128 mustard.  (That includes
        make-pair-comparator, make-list-comparator, make-vector-comparator,
        make-eq-comparator, make-eqv-comparator, and make-equal-comparator.)

    3.  Define comparators that are analogous to those returned by the
        make-eq-comparator, make-eqv-comparator, make-equal-comparator,
        and make-default-comparator procedures of SRFI 128, and also
        define an analogue of SRFI 128 default-hash, with all of these
        SRFI 125 analogues explicitly free from the SRFI 128 mustard.

    4.  Write a new SRFI that's basically the same as SRFI 128 but
        without the harmful mustard, and strongly encourage use of
        that new SRFI instead of SRFI 128.

That list is ordered from the most conservative solution I can think
of to the least conservative (but best) solution.

At this late date, I am inclined to recommend the first of those four
solutions, and rely upon word-of-mouth to recommend against use of
SRFI 128 default-hash and the SRFI 128 constructors that use it or
enforce the problematic SRFI 128 mustard.  I think that would be okay
because the SRFI 128 procedures I'm deploring here would still work
so long as their arguments are non-circular; they'd just be way slower
than the SRFI 126 hash functions.

Will