(Yes, I'm Taylor Campbell, the author of this SRFI, despite my email
address change.  I'm having mail server difficulties, which in the end
will likely result in a new suite of mail-related servers in SUnet, so
I'm using an alternate email address.)

OK, I've finally levitated my rectum and polished up SRFI 43, making it
very nearly ready to be final (not all issues have been resolved, in
case a trigger happy SRFI editor is reading this; see the bottom of
this email for the last one):

  - VECTOR-{INSERT,DELETE}! & VECTOR-ROTATE! have been thrown into the
    void.  Good riddance.
  - VECTOR-REVERSE is no more; long live VECTOR-REVERSE-COPY.
  - VECTOR-REVERSE-COPY! completes the symmetry between forward copying
    either destructively or functionally.
  - VECTOR-{ANY,EVERY} have been reconciled.
  - VECTOR-BINARY-SEARCH's CMP argument's signature has been modified:
    now, instead of it being (CMP <a> <b>) returning LT to indicate
    that A is less than B, EQ to indicate their equality, and GT to
    indicate that A is greater than B; (CMP <a> <b>) should return an
    integer, where a negative integer means that A is less than B, et
    cetera.
  - All the /INDEX variants have been further specified to apply their
    functional arguments to a list of arguments whose _first_ element
    is the index (except for the folders; see below).
  - The KNIL arguments to the KONS procedures of the folding operations
    have been moved to the head of the argument lists.  Yes, this does
    break tradition, but Scheme broke Lisp tradition, too, and this is
    a significantly less major change than Scheme was from existing
    Lisps, and in both cases the change was for the better (if you
    disagree with that about Scheme, why are you involving yourself
    with Scheme by reading this email?).
  - VECTOR-FOLD{,-RIGHT}/INDEX have been added.  The index argument
    that they apply to the KONS procedure is _after_ the KNIL but
    _before_ the elements drawn from the vectors.
  - I'm punting on the start+end versus N vectors issue: N vectors for
    any operation for which it makes sense, and start+end arguments
    fill in the gaps left by that.  Let a later array/vector slicing
    SRFI implement vector slices for those N-vector operations.
  - I've rewritten the reference implementation.  It is now more geared
    towards efficiency: argument type checks are much less redundant,
    there are several internal routines that can be wicked optimized in
    real implementations, I've lambda-lifted several things et cetera.
    For the time being, the reference implementation is available at
      http://www.bloodandcoffee.net/campbell/code/vector-lib.scm
    WARNING: It is not entirely tested.  It will be available on
    srfi.schemers.org once I update the SRFI document as well.
  - I have _not_ yet updated the document.  Read the comments I wrote
    in the reference implementation; they're more up to date.

There is a solitary remaining issue: should VECTOR-REVERSE-COPY! be
defined if TARGET & SOURCE are the same -- in terms of EQ? --? and if
so, what shuuld its semantics be?