> My point is that if `open-process' and `uri-decode-string' are native,
> unportable procedures there is no need to call them in a portable way.

There is, from within a `cond-expand`. Currently it's not possible to
call implementations' native keyword procedures from a cond-expand since
the lack of portable read syntax would make it impossible to load the
file in many Schemes. 177 allows writing call/kw using only symbols,
which makes it possible to call native keyword procedures with standard
read syntax. That's one of the major wins IMHO.

> If, on the other hand, they are rewritten following some portable
> specification (e.g. some procedure in SRFI 170), they don't have to be
> implemented using some native, non-portable keyword system.

The usual wisdom in software development is that it takes years for a
big system to be fully upgraded. By contrast, 177 could be used today to
call any native keyword procedure in any implementation, at no cost to
people who don't want to use 177.

> I don't want to say that this SRFI is useless.

No worries, I'm not offended by strong criticism. Whatever gets the best
technical result. There are justified rationales that 177 is useless or
harmful, and I respect that opinion. I agree with the internal logic of
those rationales but not with their premises. I'm open to changing my
mind about the premises if there are especially convincing arguments.

> I would, however, like
> to see that whatever simple "native keyword system" R7RS-large chooses
> for other SRFIs is also covered by SRFI 177 so that the rest of
> R7RS-large does not necessarily have to refer to SRFI 177. For
> example, I would like to be able to write something simple like
> `(make-hash-table (make-eq-comparator) 'initial-size 1000)' without
> the need of any `call/kw'.

This discussion has tipped me over to favor bending the rules of the
R7RS-large charter so that keywords (if they are adopted in the
standard) would be added to the native procedure call syntax. It's clear
that the `call/kw` prefix is considered too heavy to be part of a
standard language, and shorter prefixes like `kw` or `:` seem to me a
bit like "squirming in the hook" to avoid a problem that is ultimately
inevitable :)

The unfortunate thing is that if R7RS-large procedure call syntax is
extended, we have the Kawa/Racket direction and the CL-style direction
to go in. Reconciling those would not be easy.