Making Gauche catch up with the editor's draft. What is the default value of buffer-mode in open-file and fd->port?
Unspecified, but probably it would be good if it were the same as whatever the implementation does when opening a port using R7RS-small procedures.
fd->textual-input-port etc. specified block to be the default. It's right that open-input-file etc. doesn't specify buffering stuff at all, but I don't see harm to defaulting to block here, which seems a natural choice. But I can live with it unspecified.
Also, fd->port doesn't mention about dup()-ing fds, and from its description I assume closing the port created by fd->port doesn't close the fd, correct?
That's also unspecified. I think this is safe for SRFI 170, because there is nothing else you can do with a fd. Other low-level operations that take fds are the responsibility of the Scheme implementation. If you use a whitelist (rather than the default Posix blacklist) for fds to be left open after exec(), leaking fds to the child process shouldn't be a problem.
I'm less sure about this, for it is difficult to change, once an implementation makes a choice, and implementation-specific code depending on the behavior is built up.
However, the "it is an error if a port already exists that encapsulates fd" phrase implies that an implementation is expected to track fd and port associations in some way. If that's the case, double-closing problem (closing fd that is still used by a port) can be avoided, and the implementation can later also incorporate GC-ing fd (e.g. one can mark fd to be closed once the port is closed). If my interpretation of the implication is correct, probably it's ok.