[Harold:]
> that there are some popular use cases where already having a file
> descriptor, you prefer operating on it instead of the file name.

+1

[Shiro:]
> I have a mixed feeling of this.
> In each specific implementation, non-dup port-fd is definitely a
> requirement, for it is needed to implement low-level stuff.  However,
> such code is inevitably implementation-specific.

It's also a very simple procedure. I agree that it's nice to have.

> - Showing port's underlying fd for diagnostic purpose.

+1

> - To pass the fd to other fd->*port, effectively dup()-ing port.  It can
> be done with duping port->fd, but it saves one intermediate fd.

Sounds like it could be useful in special circumstances. But a generic
`copy-port` procedure would probably be safer for most uses. It can take
care that buffering is in sync and other such things.

[Harold:]
> So while using its result is obviously dangerous, and should be
> described as such, I think we should keep it in the SRFI 170 API,
> although I'm not sure about the best name for it.

If we want to emphasize that operating on fd numbers is dangerous, one
way to do that is just to use longer names:

- port-file-descriptor (just return the existing number)
- copy-file-descriptor (dup() and dup2())
- close-file-descriptor (close())