>>> Why not combine open-file and
>>> fd->*port in one? All other procedures either take pathname or a port.
>>
>> POSIX open() takes a whole bunch of flags which are relevant when
>> opening a pathname and don't have much to do with converting an
>> already-existing fd to a Scheme port.
>> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html>
>
> So the new open-file also takes a bunch of flags and returns a port.
> Since there's no way for you to get hold of an fd in the first place
> (unless you count on special numbers 0, 1 and 2), converting an
> already-existing fd to a Scheme port is a moot point.

A child process using a known fd number (e.g. 3) from its parent (or
from its predecessor before execve()) is a good convention for IPC.
Hence it ought to be a useful feature to open a known fd as a Scheme port.

If some C API outside SRFI 170 returns an fd, being able to turn that
into a Scheme port is also good.

If open-file takes an integer (giving the fd) how would it interpret its
flags argument?