> This problem can be avoided with the (call/kw a b c (d 4 e 5 f 6))
> syntax but other people didn't like it :)
This syntax is better than having to rely on a hack. As long SRFI 177 is compatible with native systems, people can still use native syntaxes if they like them better or add the hack with the ":" parsing themselves. For that, it doesn't have to be part of the language standard.
What people objected to was the parentheses, which were only necessary to make a syntax-rules implementation possible. Now that we have abandoned that goal in favor of define-macro, syntax-case, and explicit renaming implementations (which covers essentially all Schemes), a syntax like
(call/kw a b c &kw d 4 e 5 f 6)
is perfectly feasible and I think desirable. No problems with colon identifiers or with #: lexical syntax extensions. Then the only special case is &kw (or whatever other identifier seems desirable), which becomes in effect a syntactic keyword of this macro, like else and => in cond.
Perhaps of interest: Chicken has recently changed so that keywords are not symbols (they are disjoint at run time) and not identifiers either: they cannot be rebound.
This works for case-lambda because the different paths are only distinguished by the number of arguments and there is a small subset of often used numbers of arguments. For keyword arguments, this does not work as there is no small subset of "usually" used keyword arguments.
There might be, and indeed compilers could collect information about which keywords are used relatively easily and cache it for use or modification by other compilation runs. This is like doing permissive type inference and saving the evidence. But that's by the way.
> There should be a way to write wrappers for "procedures" taking keyword
> arguments. In particular, there has to be a way to pass keyword
> arguments down to callees.
As I noted earlier, this feature (CL &allow-other-keys lambda keyword and :allow-other-keys runtime keyword) is interesting and occasionally useful, but I would not call it necessary.