> (foo a b #:key1 c #:key2 d)
>
> could be equivalent to:
>
> (foo a b (symbol->keyword 'key1) c (symbol->keyword 'key2) d)
>
> if keyword objects in argument positions are not recognized as
> ordinary values but as markers.
>
> On the other, if `key1' and `key2' are bound as identifiers (!) to
> keywords (in the sense of some version of SRFI 177), the following
>
> (foo a b key1 c key2 d)
>
> can still mean that `c' and `d' are extra keyword arguments because
> they expander would inspect the bindings of `key1' and `key2' first.
>
> Of course, this will only work if calling procedures with keyword
> arguments is recognized at expand time vs. run-time. For anonymous
> procedures with keyword arguments, we would therefore have to use a
> construct like `keyword-call'.

This would work well for CL-style keyword arguments, but would it work
for Kawa/Racket-style keywords-as-markers? As far as I can tell, those
currently rely on the fact that the markers are read in as keywords,
i.e. their bindings don't need to be looked up at all. Wouldn't the (foo
a b key1 c key2 d) solution require the compiler to look up the bindings
of key1 and key2 before deciding that they indicate keyword arguments?
If the same identifiers are imported with non-keyword bindings, that
would change the interpretation of the whole argument list. (In
fairness, CL-style keyword calls are also liable to have their whole
interpretation changed in that scenario.)

If I understood correctly, the main advantage of Kawa/Racket keyword
markers is that the compiler knows their interpretation cannot change
based on bindings and evaluation, so it has more freedom to check and
optimize things more easily.

In case Per is lurking, could you explain this to us please? :)