When we approved CompleteSequenceCowan in ticket #64, we adopted SRFI 43 syntax and semantics for vector-copy, meaning that it takes optional start, end, fill arguments. This is inconsistent with various other copier procedures in R7RS as inherited from R5RS, as well as what is provided in SRFI 43 and its relatives SRFI 1 (for lists) and SRFI 13 (for strings). I see four plausible courses of action:
Do nothing (default): The only virtue here is that it requires the least thinking and editing. It's fugly and I don't want to go (or rather stay) there.
R5RS: Claw back `vector-copy` to just accept the source vector, all of which is to be copied. This provides self-consistency, consistency with R5RS, and maximum simplicity. The SRFIs will be provided as R7RS-large packages which will export the more complex and powerful versions.
SRFIs: Enhance vector-fill!, vector->list, string->list, string-copy, string-fill! to support optional start and end arguments. This provides some self-consistency, backward compatibility with R5RS, consistency with the SRFIs, and some loss of simplicity.
SRFIs-plus: Same as SRFIs, but also add optional start, end, fill arguments to list-copy and optional fill argument to string-copy. This provides maximal function, full self-consistency, backward compatibility with R5RS, and backward compatibility with the SRFIs.
The WG decided to adopt the "SRFIs" option above.
I mean to say that the SRFIs will be provided in R7RS-large in any case, as WG2 has already voted them in. That part does not depend on our choice here.