> It has been argued that "procedures" taking keyword arguments shall be
> first-class procedures (so they cannot be implemented as macros, which
> I would have preferred).

My argument for that is just compatibility and uniformity. For example,
if an RnRS procedure is extended with keyword arguments, that can't be
done in a compatible way if the keyword procedure cannot act like a
normal procedure in every way.

> First-class procedures with keyword arguments without any way to
> forward unknown keyword arguments lose much of their power, though.
> Thus, I think that if we want first-class procedures with keyword
> arguments, we also need some mechanism to forward unknown keyword
> arguments.

I agree; it would be great to standardize that mechanism!

177 cannot can only have things that all implementations already supprt.
But nothing stops us from writing SRFI 178 with a lambda/kw that
supports allow-other-keys :) If it's a compatible superset of SRFI 177
functionality, then users can import whichever SRFI they like. It's also
possible to define another macro like `lambda/kw*`. But maybe it's best
to extend lambda/kw. In either case, we should study how Gauche does it,
since it has the most comprehensive allow-other-keys handling (it can
separate recognized keyword args from unrecognized ones, as Shiro
explained).