> With green threads the binding of the current directory parameter can be copied to the process’ cwd on calls to C funtions (that care about the cwd).  This could be done automatically by the FFI, possibly with some hints from the programmer.  Many Schemes only have green threads.

Some OSes have per-thread cwd's so it's not that simple. You'd have to
keep track of each thread's OS and Scheme cwd (and differentiate per
OS). On each FFI call, you check which thread you're on, whether the
Scheme cwd has deviated from the OS cwd, and do chdir() if it has.

FFI functions can call C code that changes the cwd, so Scheme's idea
might be wrong.

Another problem is the current directory disappearing from underneath.
chdir() can fail; if that failure is delayed to an unpredictable FFI
point, it can cause confusing error scenarios.

More generally, I would try to avoid any unnecessary FFI complications.
FFI complexity and non-portability is one classic stumbling block for
wider library coverage in languages. (And adds maintenance for
implementors.)

> It could be part of the spec that (current-directory string) only sets the process’ cwd when not in the scope of a parameterize, otherwise it simply sets the latest binding.  So this API (using parameter objects) can express the same cwd mutations as the proposed (set-current-directory! string), but has the advantage of allowing dynamic binding for procedures such as open-input-file that need to resolve relative file names.

This means that library code has no way of telling whether the OS or
Scheme cwd is being used. Ideally the code shouldn't have to care, but
abstractions are leaky.

This is unwise on another count as well: A pathname is not a reliable
way to refer to the current directory since that directory can be
renamed (e.g. finding a shell prompt's pwd messed up after you have
moved a directory).

It is now possible on many systems to open() a directory and use
openat() to parse pathnames relative to that directory, even if it has
been renamed or moved. This is often sound practice, esp. in long
running daemons.

> In any case, in a truly parallel setting, some synchronization is required around the mutation of the process’ cwd whether (current-directory string) or (set-current-directory! string) is used.
As far as I can tell, it's not required if we don't have any Scheme
variable to synchronize and Scheme simply defers to the OS.

This is similar to the situation with file descriptor numbers vs Scheme
ports. I would advocate that we don't even attempt to do any fancy
abstraction to keep the two worlds in sync and hide the boundary. The
ramifications are so complex that we'll never get them right, and it's a
decent bet that these things get more complex with every passing decade.