Will address the other issues and previous emails later if needed, for
John is vetoing a new SRFI, and I don't disagree, scoping of what's in
SRFI 170 is in his remit, and there's a lot to be said for keeping the
fd stuff in it, for example see below:

> From: Duy Nguyen <xxxxxx@gmail.com>
> Date: Thursday, September 10, 2020 12:50 PM
>
> On Fri, Sep 11, 2020 at 12:36 AM <xxxxxx@ancell-ent.com> wrote:
>
> [...]
>
>> As mentioned above, keep the now fully admitted hack of
>> port-terminal-fd in SRFI 170, because it's easy/trivial, is
>> needed by 170 and we don't want to indefinitely further delay
>> 170's finalization.
>
> Easy and trivial does not make a good design. Removal would not
> definitely delay finalization.
>
> It's my bed time now perhaps I'm skimming your mail too fast (in that
> case I apology and will read more carefully tomorrow) but why are fds
> still needed by 170? terminal? is moved out. IF fd->*port are combined
> with open-file then there's no where else fd is used. Or I'm reading
> the wrong version.

And I your's, since I've finished my first and only all but guaranteed
high productivity part of the day.

port-terminal-fd is needed to avoid duplication of implementation code
in future SRFIs.  Under the table, mapping from a port to a fd is
required for SRFI 170 truncate-file and file-info, it's required in
SRFI 205, it would most likely be required in the posited but
currently vetoed New, Improved ports and fds, "expert" or not SRFI(s).

Nailing it down in the earliest SRFI makes implementation for all of
these much more sane.  And provides a clear path to finalization SRFI
170 ASAP, with or without the ports/fd APIs, and terminal?

And given John's current path, keeping terminal? in SRFI 170 is I
think a good idea, again because it's also trivial given
port-internal-fd.

Whereas for example SRFI 205 will be somewhat complex, and aside from
the new grab bag scsh procedures, is currently for a couple of special
use cases, serial port I/O for e.g. embedded programming, and safe use
of raw etc. mode. for terminals including a posited future Terminal
User Interface (TUI) SRFI.

And the reason these two are packaged together is again
implementation, they use the same stty mechanism under the table.
Which we've decided we won't expose in its full glory, much is now
obsolete, we do not plan to support retro-computing, e.g. a Scheme
program that simulates an old machine down to real serial lines.

- Harold