> portable code won't use keywords anyway for now.

You're right. It's not that good to encourage non-portable code. I'm not
sure whether optional keyword support would do that. Most Schemes don't
have keyword read syntax, so anyone aspiring to use keywords would get
stuck with that higher-level problem before we get to specific APIs.

I view the problem as similar to accepting strings vs pathname objects
for filename arguments (at least Kawa and Racket have such objects).
Pathname objects are not portable, but that's well known, and they make
for more idiomatic APIs in the Schemes that have them.

> When we have a keyword srfi we can agree upon, we can make a srfi
> that enhances srfi-198 with keywords.

I was hoping to avoid that situation :) As far as I can tell, the only
place we'd need keyword support in 198 is when passing properties to the
constructor (make-foreign-error or raise-foreign-error). IMHO it would
be nice to address the situation now rather than write a new SRFI later
just for this one small change.

It would also allow more idiomatic code in Schemes that already have
keywords like Gauche, and in a Common Lisp port.

Requiring symbols instead of keywords in `foreign-error-ref` matches the
CLOS `slot-value` accessor, which also uses symbols
(http://www.lispworks.com/documentation/HyperSpec/Body/f_slt_va.htm). It
also respects the convention that each keyword in lambda lists should
have a matching value (like a property list / plist). (However, this
latter convention is not strictly enforced in the CL-style keyword call
convention).