I do not believe in providing library functions for arbitrary special
cases that might all be expressed in terms of a single more general
function. In fact, I consider this attitude to be one of the great
differences between Scheme and Common Lisp. Several of the comments
below are biased by this conviction.

4.1 Constructors

The function vector-iota is simply a not particularly interesting
special case of the function vector-tabulate. Is the desire to mimic
SRFI-1, which in turn is inspired by APL, sufficient to introduce this
function?

4.2 Predicates

Is the pathological case of a vector with no elements really common
enough to warrant the introduction of two predicates that could be
implemented in terms of vector-length? Lists and vectors are pretty
different in this regard.

4.3 Accessors

While first, second, etc. are certainly more legible than car, cadr,
etc., this does not apply to vector-first and friends, which are
simply not-so-short shorthands for (vector-ref vec index). Indeed,
since the indices of vectors are zero-based, the ordinals might even
be considered misleading. Of course, this also applies to list-ref,
but referring to list elements by index seems to be less common in the
lisp community.

The vector-take and vector-drop functions are all variations of a
single theme, namely selecting a sub-vector, and could all be replaced
by the function vector-copy, defined as a constructor in section
4.1. In this regard, vector-copy is more powerful than the function
list-copy defined by SRFI-1.

4.4 Miscellaneous

I am not sure whether the limitations of some scheme implementations
with regard to the length of argument lists should enter into the
definition of a SRFI. If it should not, the function
vector-concatentate* is simply superfluous, and even if it should, the
function is inappropriately named, as the asterisk usually implies
left-to-right evaluation rather than a certain argument type.

Nor is the name of the function vector-zip very helpful, as "zipping"
usually refers to some kind of compression. And again, is all this
"unzipping" really common enough to warrant the definition of five
additional functions? And yes, this also applies to SRFI-1.

4.5 Iterators

If vector-unfold is the fundamental vector constructor, it should be
defined in 4.1 and not 4.5. Moreover, vector-unfold is hardly a
suitable name for a constructor. As the function is similar to "do"
returning a vector, the syntax might be changed to reflect this
similarity. On the other hand, this would break the similarity to
SRFI-1.

Given a not too inefficient implementation of vector-reverse, which
should be possible, the whole issue of left/right iteration would seem
rather pointless.

4.9 Association Vectors

Who needs association vectors in addition to association lists and
hash tables? What are their advantages? Or is a strict translation of
SRFI-1 the main motivation for their definition?

Disclaimer: I realize that many of the names shadow those introduced
by SRFI-1, but that does not necessarily make them any better.