I think the primary rationale for using symbols was that I wanted short names for the common variables, which would be too likely to conflict with variables in user code.
I don't think that that would be much of a problem as imports from R7RS libraries can be renamed or prefixed. In fact, SRFI 159 already exports a number of short identifiers that could equally likely conflict with variables in user code (like `with' or `each' or `nothing'). Again, it is easy to prefix these in case it's needed.
It's worse than that though, since the identifiers conflict with themselves - you're likely to want nested formatters referring to the `col` variable (the ref impl does this), for instance, and this would no longer be possible without renaming.
Conceptually, these variables are a runtime mapping (alist but could be hashmap), not a fixed record, so the analogy you propose isn't valid. Not only is it strange to generate identifiers at runtime, it's not possible in portable R7RS small. For example, if you want to load `show` templates dynamically from a text source (e.g. from gettext translations) then you really want to work with symbols, not identifiers.
--