Date: Wed, 28 Oct 2015 09:26:00 -0400
   From: John Cowan <xxxxxx@mercury.ccil.org>

   I'd like to take a straw poll on how best to resolve the conflict between
   R7RS-small and SRFI 43, the existing vector library that I intend to
   propose as part of R7RS-large.  The conflict happens with the functions
   `vector-map` and `vector-for-each`.  These have the same signature in
   both libraries, but invoke their procedure argument in different and
   incompatible ways.

I doubt whether SRFI 43 matters to anyone.  One is better served all
around by foof-loop than by SRFI 43.

   1) Live with the problem.  This means that importing SRFI 43 into
   an environment that already contains (scheme base) will cause import
   conflicts that must be resolved by excluding or renaming.

Preferred.  This is a problem that one may have to deal with in any
sufficiently large and diverse code base.

   2) Fork SRFI-43 minimally.  Rename the procedures to `vector-map/index`
   and `vector-for-each/index` or the like (something better, preferably).
   This resolves the conflict, but is fairly unmotivated in SRFI 43 terms.

Reasonable.

   3) Fork SRFI-43, doubling up on all procedures with procedure
   arguments.  This would mean introducing two forms of the seven such
   procedures, `vector-fold`, `vector-fold-right`, `vector-reduce`,
   `vector-reduce-right`, `vector-map`, `vector-map!`, and `vector-for-each`:
   one that accepts an index (and has a name ending in `/index`) and another
   that does not (re-exporting the names `vector-map` and `vector-for-each`
   in an R7RS context).  This is a full solution, but adds more names and
   complexities.

Reasonable.

   4) Introduce some new mechanism into Scheme to figure out whether the
   procedure being passed as an argument wants an index or not.  Simple arity
   inspection does not suffice, as the procedure may be written to handle
   an arbitrary number of arguments.

Sounds awful.