> You seem to use the term "fully interoperable" in trying to explain
> what you mean by "interoperability". I am still not convinced that
> this means much for all practical purposes.

As far as I can tell, it covers the most important use cases ("the 80%
case").

With 177 these can already be done, for example:

;; Gambit
(open-process (call/kw list (path "ls" arguments '("/bin"))))

;; Gauche
(call/kw uri-decode-string "hello+wörld" (cgi-decode #t encoding "utf-8"))

Note that the Gambit example calls `list` with keywords and it still
works! Gambit has self-evaluating keyword objects, so those actually go
into the rest argument of `list` in Gambit's evaluation model.

Likewise, you can (define/kw ...) things that can be used seamlessly
with the existing keyword syntax and function call semantics of those
Schemes.

I don't see how the focus of the SRFI could be any more practical than
this. All you have to do to get all of this is to type an extra
`call/kw` in a few places, and even that only concerns people who want
to use the SRFI instead of the many other compatible keyword systems.

The SRFI could be much better from purity standpoint, to be sure. I'll
happily incorporate anything that doesn't detract from its practicality.

It could also be more versatile (e.g. allowing a keyword argument to be
bound to an identifier with a completely different name). I'd leave this
to fancier keyword systems that are compatible with 177. I never
intended for 177 to have a monopoly on keywords, but the exact opposite.