Here are some comments on Draft #8 (2016-05-06) of SRFI 125.  They are
all quite minor.

  * Constructors section, 2nd para: I believe the intent is to
    indicate that an implementation may use a hash function different
    from the one specified (within the comparator or separately in the
    deprecated form) when the equality predicate provided (also within
    the comparator or separately in the deprecated form) is a
    refinement of equal?.  If this is correct, then the wording
    "implementation-dependent hash function instead of the
    equality-predicate" seems confusing to me.

  * hash-table: Is something like the following an error? If not, which
    value is associated with 1?

      (hash-table (make-eqv-comparator) 1 10 1 20)

  * hash-table-set!: Is the order in which the hash table is
    repeatedly mutated restricted?  In particular, what is the
    behavior when some key is repeated in the arguments (or is that
    disallowed)?  The convention used for alist->hash-table would
    suggest a result consistent with a right-to-left repeated
    mutation, but I'm unsure.

  * hash-table-pop!: The sample implementation expects an additional
    (failure) argument.  Also, shouldn't there be a performance
    guarantee here similar to those in earlier procedures?

  * hash-table-map: The sample implementation expects an additional
    (merger) argument.

  * Implementation section: typo "any any"

  * (somewhat tangential and very minor) The "Last modified" tag at the
    very end of the Web page seems like it doesn't get updated (still
    shows Aug 2015).  It just gave me a fright when I got to it,
    thinking I may have wasted time reading a long obsolete version in
    detail.

Regards,

-chaw