My only add here is that I implemented SRFI 88 & 89 for my own system. 88 is optional and enabled with #!srfi-88 and can later be turned off with #!no-srfi-88. They set/clear a parameter associated with the port being read, in a manner consistent with #!fold-case and #!no-fold-case.
I don't actually use the keyword functionality that often, mainly because of little support in the community, though I do like to use define* and lambda* from (srfi 89) for optional argument handling. Where syntax-rules macros use strings as literals in patterns to trigger internal states, srfi-88 keywords are slightly nicer because they compare faster. Of course there are good reasons for library code to use "private" identifiers for this purpose. But where we have had the debate of whether some syntax should to symbolic-matching vs. syntax-rules-style literal-identifier matching, I often wonder if the using keywords would simplify life in situations where the symbolic (eq?) matching makes more sense.
The most common incompatibility I run into is syntax-rules code that uses ::: as an alternative ellipsis, which must be an identifier.