There are two choices for ordering bytevectors, somewhat dependent on
how we interpret them.

Lexicographical order: Comparing octet-by-octet from the beginning.
If one octet is smaller, the bytevector that have it is smaller.  If
all octets are equal up to the point where one bytevector is
exhausted, the shorter one is smaller.   This is reasonable if we view
bytevectors as a string of octets, where left-to-right order carries
some significant meaning.

Length order: Compare lengths first.  If one is shorter, that
bytevector is smaller.  If both are the same length, use
octet-by-octet comparison for the tie-break.   This is faster.  If we
view bytevectors as random-accessible array of octets, this has
advantage.

We have precedents for both.   SRFI-207's bytestring<? etc. adopts
lexicographical order, which is natural since the srfi specifically
regards bytevectors akin to character strings.  SRFI-128 (scheme
comparator) takes the latter view, regarding bytevectors as akin to
general vectors.  Note that this is the order used by the default
comparator as well.

I think both are useful depending on the context.   If I need to
choose, I suggest to keep bytevector<? etc. consistent with the
default comparator (length order), and incorporate bytestring<? from
SRFI-207 for lexicographical ordering, enhancing it to take more than
2 arguments.   The name clarifies that the user wants to treat the
bytevector as a string of octets.