I keep forgetting that use case is the only reason O_APPEND exists. But to continue my half-thought about the absolute necessity of it for this proto-SRFI, you could in theory have each process write to its own file, and merge them later.
Not unless you time-stamped every write as you did it, otherwise you wouldn't know how to merge them.
In any case, appending is a great convenience: I constantly use >> at the shell level.
As far as I know, raw POSIX file descriptors don't have the sort of buffering we're desiring, they have none at all.
Yes, of course; I wasn't thinking too clearly. Buffer pertains to all ports, and char-buffer and the encoding keys pertain to textual ports specifically. The mode (read, write, both) pertains to both fds and ports, and will require more thought.
Breaking up the work into smaller blocks has its obvious advantages, but when getting into something that gnarly I prefer to do it all at once, however it's sequenced. Given that a implementor may have to change the architecture of their port implementation, it's best that they have as few sets of requirements as possible before they start, ideally there would be only one.
Adding open-file to SRFI 170 with keywords is a no-brainer, I think: we'll say that 170 depends on 177, and rig the ballot so that a vote for 170 is a vote for 177 as well. I did this with 128 in the Red Edition; it's appropriate whenever a SRFI's interface, as opposed to its implementation, depends on another SRFI.
What to do about the R[567]RS procedures is more difficult. Because of call/kw they aren't just drop-in replacements as I had originally intended. I think the simplest thing is to make the fdes->port functions keyword-based.