I agree that this is a problem.  What I'd like to do is remove the relevant sentence from SRFI 133 and adjust its sample implementation accordingly, adding a post-finalization erratum to SRFI 133.  This result is really unexpected.  Historically, the sentence in question originated in SRFI 43 (2004), which is before +nan.0 was a standard part of Scheme.

Arthur, how do you feel about doing that? The sentence to be removed is "Element comparison must be consistent with eq; that is, if (eq? Ea Eb) results in a true value, then (elt=? Ea Eb) must also result in a true value".  Here's a proposal for the erratum:

Post-finalization erratum:  The finalized version of this SRFI required the equality operator used by the vector= procedure to be consistent with eq?.  However, = is not consistent with eq? in a Scheme which provides NaN values and IEEE semantics for them, as (eq? +nan.0 +nan.0) may return either #t or #f but (= +nan.0 +nan.0) must return #f.  This means that the expected semantics of = when used with vector= are violated.  Therefore, the requirement for consistency has been removed from this version, and the sample implementation adjusted accordingly.

If this is unacceptable, I'll add a note to SRFI 160 saying that the consistency requirement does not exist in SRFI 160.  I consider this an inferior solution, however.

Except that (eqv? +nan.0 +nan.0) can evaluate to either #t or #f (see the description of eqv? in R6RS or R7RS) so you just don't know what you'll get.  In addition, comparing a general vector of exacts with a general vector of inexacts will always produce #f if you use eqv?, which may not be what you want.

--