I agree that this SRFIs current optional arguments specification is
cognitively cumbersome.  Beyond the cognitive burden, it also makes static
analysis of code very difficult.

I also agree comparisons should be the first argument (if used), and I'm not
averse to requiring the compare procedure, but I realize it's verbose.

Would the following work as a reasonable compromise?

procedure:  ((=? [ compare ])  x y )
procedure:  ((<? [ compare ])  x y )
procedure:  ((>? [ compare ])  x y )
procedure:  ((<=? [ compare ])  x y )
procedure:  ((>=? [ compare ])  x y )
procedure:  ((not=? [ compare ]) x y )

A few examples for illustration
   ((>?) "laugh" "LOUD") ===> #t
   ((<? string-compare-ci) "laugh" "LOUD") ===> #t
   (define char<=? (<=? char-compare))
   (sort-by-less '(1 a "b") (<?)) ===> '("b" a 1)
   (sort-by-less '(1 a "b") (>?)) ===> '(1 a "b")

This has the added benefit(?) that you can now drop `?' since =, <, >, <=, >=
are not defined on 0 or 1 arguments, thus:

(= 1 2)   ;; performs a test with R5RS semantics.
((=) 1 2) ;; performs a test with SRFI-67 semantics.
(=)       ;; returns a procedure of arity 2 with SRFI-67 comparison semantics.
(= c)     ;; returns a procedure of arity 2 with SRFI-67 comparison semantics.

David