While we're still cogitating about whether to split out processes from this SRFI, as previously discussed, let's examine the procedures that take a port as well as a filename to see if taking a port makes sense. While we're at it, consider if taking a file descriptor also makes sense, for that is utterly trivial since converting from port to fd is the first step you take if handed a port. It's also pretty easy to handle port/fd, generally you have to wrap another system call that looks just like the one that takes filenames, and hand it the file descriptor instead of a filename. But every bit of additional stuff adds up in what's already a monster SRFI:

(set-file-mode fname/port mode-bits)

(set-file-owner fname/port uid)

(set-file-group fname/port gid)

(set-file-timespecs fname/port [access-timespec modify-timespec])

(truncate-file fname/port len)

These two are a little different, in that the underlying system calls only take a file descriptor, but of course with not much work adding opening and closing a filename is easy:

(tty-process-group port/fname)

(set-tty-process-group port/fname process-group)

I personally have no ideas or feelings about any of these except set-file-timespecs, the scenario being that before you mess with a file you use file-info on the filename to get the access time (I'm assuming that doesn't change it before you get the times), and after opening it you use set-file-timespecs to set the access time back to what it was.  Although that's in the context of backup programs, which this SRFI does not support due to ignoring symlinks, and I suppose without including lseek it can't, since that's needed to restore sparse files.