First of all, many thanks to Olin for this SRFI.

It is very relevant, clean, and insightful.
How about having a "Best SRFI Award" at some conference each year? :-)

...-delete-neighbor-dups...
These are the only function names containing abbreviations.
Why not replace dups by duplicates? No, it's not so much longer (relatively).

Bigloo:
sort vector-or-list <
(If you need details: it is implemented in runtime/Ieee/vector.scm and
runtime/Clib/cvector.c (sort_vector).)

Ordering function first.
Yes, please. You have to modify existing code (function names), so you
can also modify the parameter order, don't you?
(or even better,  your order is already function-first :-) )

vector-binary-search.
Yes, please. (It's related to sorting through the comparison problem.)

"Porting and optimization"
RECEIVE: You could advertise SRFI-8 (receive: Binding to multiple values) here.
ERROR: You could advertise SRFI-23 (Error reporting mechanism) here.
LET-OPTIONALS: maybe one can use SRFI-16 (Syntax for procedures of variable arity)
  instead.
Then, your considerations about (QUOTIENT N 2) would normally lead to
using your own SRFI-33 (Integer Bitwise-operation Library).

typo: bewlow -> below

unspecified/unspecific: choose one term (maybe the first).

I'm not sure about the next point, so I put it last:

Comparison predicates.
I saw the discussion about < and <=. But is not a three-valued comparison function
(symbols less, greater, equal) more efficient for some data types if many
duplicates are present?
I often sort lists of some million strings of average length 20 and many
duplicates. I remember that some sort algorithms will test (< a b)
and (< b a) in certain constellations for one setting of a and b.
(Olin, for things like this a look at your reference implementation would
be helpful, although concentrating on the design was a clever move for
the discussion so far.)
A three-valued comparison function also speeds up vector-binary-search.
A problem for three-valued comparison functions is that their implementation
can range from efficient to inefficient:
- you can write an efficient string-compare for strings
- but, for numbers you would need support from the underlying Scheme system
  beyond R5RS (?) although an implementation using > and < is not too slow.

Greetings
Sven