These are all good points.

> I'm not convinced that direct Scheme access to low-level integer file
> descriptors and fork are useful to standardize.

I've found it very useful even in high-level languages to be able to
refer to file descriptors by number. It's true that it's not as portable
outside Unix. You can pass HANDLE values around even in WinAPI but they
are not small integers like Unix fd's (some handles are pointers cast to
integers, you have to assume a handle can be a uint64).

> Doing doing a 'fork' on the JVM using native code seems like a bad idea.

We discussed this briefly with John and agreed with you that the most
"ordinary" procedure should have the semantics of a combined fork+exec,
like start-process in Emacs or CreateProcess() on Windows.

Unixisms such as separate fork and exec should be designated as special
and less portable procedures. It might be best to leave them for their
own SRFI altogether. The current draft is based on Scsh which shows a
lot of Unix bias.

Having this division would also hopefully encourage people to prefer the
more portable procedures, resorting to the Unix-only stuff only when
it's necessary. When programming in C, people often use the
fork()/exec() abstraction because it's there and it's familiar, not
because they need that fine-grained control.

> Better to use ProcessBuilder,
> which is quite flexible:
> https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/ProcessBuilder.html

It looks similar to Python's subprocess.Popen() API
(<https://docs.python.org/3/library/subprocess.html>). That's good.

It makes sense to have a process not-yet-launched-process object on
which you can set various options (where stdin reads from, where stdout
and stderr write to, possibly other file descriptors, what environment
variables are used, etc.)

> It is better to standardize higher-level APIs. For example Kawa has a
> flexible high-level process API:
> https://www.gnu.org/software/kawa/Processes.html
The run-process function already embodies the above philosophy nicely:

(run-process in-from: "in.txt" out-to: "out.txt" "tr A-Z a-z")

pipe-process is a nice touch too. Manually constructing pipelines by
gluing together OS pipes and subprocesses is tricky.

> I build a single portable "universal" binary release for Kawa. Adding
> native code would complicate that.

Do you currently manage with only Java's standard libraries, i.e. no JNA
or JNI?