> I have limited time to contribute, but if you send me the list of OS features that are in scope I can give you a list of the Gambit procedures that are available for those features.  Beyond that I’ll try to stay tuned to the discussion.

Thanks for staying on board in any case :) I appreciate it.

What's tentatively in scope is roughly what's in the headings and
procedure names of the draft SRFI at
<https://srfi.schemers.org/srfi-170/srfi-170.html>.

Is this an up to date document of the relevant interfaces in Gambit?
<http://www.iro.umontreal.ca/~gambit/doc/gambit.html#Host-environment>

> BTW, it is sad that networking is out of scope… again… It is such an essential feature in modern apps, at least basic networking.  I think things get complex (politically) when the details of the socket interface are exposed, but there should be agreement on basic and portable features.

I don't know the history (just got into Scheme seriously this year) but
apparently there is some disagreement on whether the networking API
should be a feature-complete interface to BSD sockets, or a
TCP/IP-centric thing favoring convenience above completeness. Is this
your experience as well? I have an idea for how to reconcile the two
camps but it's still a draft of a draft...

> Is filesystem path syntax in scope?  i.e. /foo/bar vs C:\foo\bar

Yes. John and I would favor a light representation where a path is just
a string (and occasionally a lists of strings for splitting). Gambit
seems to take the same stand
(<http://www.iro.umontreal.ca/~gambit/doc/gambit.html#Handling-of-file-names>).

Bytevectors could be supported in addition to strings where an
implementation's string type doesn't permit lossless round-tripping of
some exotic pathnames (there's a lot of stuff pertaining to Unicode
normalization or lack thereof by the file system, mixing Unicode and
non-Unicode filenames in the same file system, etc.)

I have personally had a great experience with the Go/Python style
"strings with a little convenience" pathname approach. It almost always
does what you want. Common Lisp and Racket style heavy parsing of
pathnames is an admirable goal, but in practice I have found it to be
constantly confusing, very verbose and not really making code more
portable or reliable.