Do we provide a mechanism for custom ports,
on which for instance string ports could be
I wrestled with these a lot, but couldn't find anything satisfying. If you treat a custom port as an object on which you can get/set procedures to do the work, you wind up with a getter/setter for every I/O procedure you have. And you need to say what happens if the user provides only some of them. It's a big mess. You can make the procedures generic and use a symbol to indicate which property is being get/set, but all that does is clean up the page some, the implementation is still messy. Having multiple kinds of ports (binary/textual, string/file, input/output) just makes the mess worse.
I am opposed to standardization here, and I think the R6RS effort was premature.
I am pretty conflicted over this issue as well, as Oleg Kiselyov & I (and a few others) tried to work up an I/O SRFI many moons ago. Things got very complex, very quickly.
Arguably, all I/O should be moved out of the core language specification. C managed to get along with only "library" compliance in I/O for many long years. Additionally, I/O is the canonical example of where side-effects are unavoidable. Nevertheless, Scheme without a free system for reading s-expressions wouldn't feel like much of a lisp either, and the utility of the language would be significantly degraded.
The I/O library needs significant work, and I am more than half inclined to say it should be a WG2 job, except for the Lisp-y-ness issue.
WG1 voted not to have custom ports.