First, I like this SRFI -- it should have been here long ago.  I have a
few comments, though:

  - MAKE-BYTE-VECTOR isn't exactly analogous to MAKE-VECTOR[*], in that
    the fill argument isn't optional.  It would be reasonable, I think,
    to make the fill argument be optional with a default of 0, which
    would make their signatures compatible.

  - Could a BYTE-VECTOR-COPY!, similar to SRFI 13's STRING-COPY! & SRFI
    43's VECTOR-COPY!, also be introduced?  Such an operation is very
    commonly used with byte vectors, and it is generally a good idea to
    have such a low-level operation as this to be built-in to the byte
    vector interface as a primitive, rather than always defined atop it
    in utility libraries.

  - It is explicitly unspecified whether byte vectors are disjoint from
    vectors, but must byte vectors also be disjoint from strings?  MIT
    Scheme's byte vectors are not, for instance.  It would be good, I
    think, to add a note about that.

  - Though it is obviously outside the scope of this SRFI, will there
    be another SRFI or will R6RS include support for binary block I/O
    with byte vectors?  Perhaps Alex Shinn ought to be prodded about it
    in SRFI 56.

[*] - A few of the 'analogous to ...'s of your procedure descriptions
accidentally refer to the byte vector operations, by the way, not the
regular vector operations; for instance, MAKE-BYTE-VECTOR's description
says: 'Analogous to MAKE-BYTE-VECTOR.'