Finally took a look.  Thanks for the great work.  I wanted something
like this for long time but never came up a concrete spec as clean
and thorough as this.

A few points.

1. Limitations on circular structures - isn't the current wording
too restricting?  Some comparators, e.g. eq-comparator won't have
problems on circular structures.  Putting such case into "error"
(a.k.a. implementation-specific behavior) would make it hard
for portable code to deal with circular structures.  (Example:
putting circular structures into a hashtable using eq-comparator).

I can't come up better wording, though.  Maybe we can say
"The comparator objects ... are not applicable to circular
structure otherwise noted", and note the "circular-structure-safeness"
in some comparators.

2. Optional comparator in comparison predicates.  The rationale
of allowing it is "there is no comparator for comparators, so
there is no ambiguity", but why not?  There won't be a portable
way, but some implementations may allow it.

(=? comparator obj1 obj2 obj3 ...) can be written as
((make=? comparator) obj1 obj2 obj3 ...), which is a bit verbose
but I think it's much clearer and I would prefer latter.  I don't
mind dropping 'comparator' support in =? etc. and just define
=? as (make=? default-comparator)

3. Disjoint comparator type.  I have a mixed feeling on it.  It would
be convenient to have comparator? work, and it might be necessary to
overload some procedures such as 'set', which can take either a
comparator or equality predicate.  OTOH, having a disjoint type
just to bundle some procedures seems overkill in Scheme---it smells
more like class-based OO language, in which people always need to
pass an instance of a class where Lispers would just pass a closure.

BTW, an implementation may want to provide multiple comparator
types (e.g. by subclassing or duck-typing).  The "disjoint type"
clause can be refined to say from what the type is disjoint.

--shiro