>     mapfun and accumulator arguments to be optional, which means they have
>     to be at the end.
>
> Actually, they don't need to be at the end.  Mapfun and accumulator are
> procedures, which can't be parameter objects.  So, you look at the
> rest-args, see if the car is a procedure, and if so grab it and
> its successor, and now the real params are in the cddr.  Very simple.  I
> think there are already a couple of SRFIs that work like this, with an
> optional argument at the beginning even, provided it is recognizable by
> its type.

I intensely dislike that kind of magic argument parsing :) I don't think
it's simple. Argument values can come from variables, and Scheme is
dynamically typed, so a variable bound to a different type of value than
expected can transparently change the way the argument list is unpacked.
Not elegant.

A similar misfeature exists in Unix command line option parsing. Some
popular parsers let you define options that take optional arguments --
doubly optional! All to save a few keystrokes in some corner case.

Keyword arguments (or plists, which are almost equivalent) are the
standard way to do anything fancy with argument lists. Keywords need to
be spelled out so they act as documentation. That's good.

> I have a pre-SRFI for `identity` and a bunch of other small handy
> abstract things:
> https://github.com/johnwcowan/r7rs-work/blob/master/CombinatorsCowan.md.

Looks nice enough!

I'd like to look for prior art for those in the Lisp and ML families and
add to the table at <https://lispunion.org/rosetta/>. Maybe there are
some semi-standard names.

In particular, I lament that CL chose such a long name as `constantly`
for such a useful procedure; maybe there's a shorter existing name.

>     2) a `values` implementation where the single-value case (values a)
>          returns `a` with no wrapper object.
>
> #2 is a requirement going back to R5RS:  (values a) must be the same as
> a (in the sense of eqv?).

Nice!

> A good software tool, says one of the Unix gurus, is one that gets used
> in a way the creator never foresaw.

For example closures, S-expressions, and GC, none of which belong in the
Unix pantheon :)