> SRFI 177 has been advertised that it offers a portable way to extend
> an API while retaining compatibility.
>
> This is different to designing an API from scratch using keyword arguments.
>
> I strongly suggest not to do this for any API that is for inclusion
> into R7RS-large.

I'll leave the R7RS-large decision to others.

But a related concern is that some SRFI authors may want to use keyword
arguments. If you want to include some functionality in R7RS-large and
the SRFI about that topic happens to use keyword args, how will the
issue be resolved - change the API from the SRFI or design a new API?

We could have an informal agreement not to use keyword args in SRFIs
that might go into R7RS-large. My personal opinion is that that would be
a bad call, because for many complex tasks, all the alternatives to
keyword args are a poor emulation of them:

* optional positional arguments (same as kwargs with no names)
* alist or plist argument (like kwargs with no static checking or
optimization)
* record type (like kwargs, but need to define a new record type just
for one procedure)

SRFI 167 (just being finalized) has good examples:

(make-engine open close in-transaction ref set delete range-remove range
prefix-range hook-on-transaction-begin hook-on-transaction-commit pack
unpack)

(engine-in-transaction engine okvs proc [failure [success [make-state
[config]]]])

(engine-range engine okvs start-key start-include? end-key end-include?
[config])

IMHO all of these would be easier to understand (and to make
implementation-defined extensions) with keyword args.