Overall this is an amazingly rich API and I look forward to using it
when it is standardized.  I hadn't ever clocked the existence of the
previous SRFI, so this is a nice surprise.

A few miscellaneous comments:
I find it strange initially that I'm forced to specify the various
arguments for 'make-inexact-comparator'.  I would like to have
optional arguments that simply use the default behaviour of the =
operator (for instance) if I don't specify the argument for 'epsilon'.
 I guess the intention is that if I want a less specific behaviour I
can use the numeric comparators under the 'Standard atomic
comparators' section, or 'default-comparator'.

Why not let the user specify the actual rounding procedure to use for
the rounding parameter of 'make-inexact-comparator', instead of using
a symbol?  Performance?

I don't really see the need for the procedures under 'Primitive
applicators'.  They are just sugar, I guess, unless the results of the
accessor procedures are intended to be totally opaque.  (except for
comparator-check-type which has additional semantics).  i.e. can the
semantics of (comparator-hash comparator obj) differ from
((comparator-hash-function comparator) obj)  in any way?

I'm a little worried that the binary comparison predicates look too
similar to the existing base comparison predicates.  (=? c x y) is
fairly visually similar to (= c x y).
Also not sure of the use case for allowing ((=? cmp) x y) as part of
the same procedure, I see that this is useful for expressions like (<?
cmp) where the resulting procedure is not identical to the result of
'comparator-compare-procedure', but maybe bundling this neat currying
behaviour under general comparison is muddying the waters.

Nice work!

Cheers,
--
David Banks  <xxxxxx@gmail.com>