> Why do we need call/kw at all?

John said it well: "The importance of native keyword support isn't just
efficiency, it's interoperability between native code and portable code,
and SRFI 177 is careful to preserve that."

The main goal of 177 was to go out of my way _not_ to invent anything
new whatsoever :) There is nothing in it that isn't already supported by
_all_ existing Schemes I could find.

> Chibi-style keywords need not be a performance hit with compiler macro
> support.

That is interesting to know. Like John, I was unaware that they could be
made equally fast.

> I'm not necessarily arguing for this, but it's typical to mention prior
> art and alternate approaches in a SRFI.
> SRFI 177 instead goes out of its way to mention every other approach to
> keywords except Chibi's.

Sorry about the omission. I wasn't aware of let-keywords when I wrote
draft 1, and didn't realize until now that you intended it to be an
alternative on equal footing with the native keyword systems in other
Schemes. I thought it was meant as a a higher-level utility, in the same
sense as `match` is a higher-level utility than `case-lambda`. Though
perhaps a sufficiently smart compiler could optimize `match` like it
optimizes `case-lambda`.

I'll include let-keywords in the next draft's rationale.

> If performance really matters and we want to rely on it consistently,
> one option is to abandon lambda/kw and
> make define/kw define a syntax which can be called directly without call/kw.

Marc proposed that approach, and it's still in the cards for 177.