> The syntax of SRFI-177 is too heavy, and it requires to learn new
> things in scheme.
>
> So far the arguments in favor of keywords like SRFI-177 are:
>
> - Performance
> - Programming in the large
> - Scripting
>
> In scripting, performance does not really matter. In programming in
> the large, companies can invest in better compilers.

I agree that performance is not a significant problem. It's nice if
calls can be really fast, but I still haven't seen a case where keyword
arguments are needed in the fast path of performance-sensitive code
(graphics, etc.) They tend to be the most useful at the exported API of
a module, called more rarely than the internal procedures.

> That is case of for let-optionals and let-keywords (or similar
> approach relying on rest arguments). This does not introduce a new
> syntax, it is a good uses case for macros, it is portable, it does not
> introduce new things to implement in scheme standard and the syntax is
> clean.
>
> What precludes those macros as keywords facility and as the way-to-go
> for R7RS libraries?

I think I understand your argument, but I have the opposite point of
view: it's macros like `let-keywords` that indicate a problem. It's
similar to exception handling or object systems - while it's true that
everyone can write their own system, that makes it difficult to write
standard tools, and it means different codebases end up doing the same
thing slightly differently. One of my favorite things about Scheme is
how similar code looks in different codebases.

In the case of keyword arguments, as one example documentation
generators are easier to write if there's a standard way to do keyword
arguments (and optional positional arguments - that's currently done
with case-lambda). Compiler optimizations also become possible.

SRFI 177 is approximately as portable as let-keywords; that was the big
win and surprise about it. You're right that let-keywords doesn't need
to be customized for each Scheme implementation, but we're talking about
a very modest amount of code even with separate implementations.