>     We discussed adding 170 to Gambit with Marc, and he again made the case
>     that requiring the Scheme CWD to be equal to the OS CWD is not
>     practical for multi-threaded programs.
>
> I don't understand the reasoning behind this.  Posix describes chdir()
> as per-process, so changing it will affect all threads.

Here are the arguments from <https://github.com/udem-dlteam/libs/issues/13>:

> chdir and OS threads are simply incompatible (because the CWD is a per process thing so shared by all OS threads). So defining filesystem access procedures that are sensitive to the per process CWD makes it impossible to use those procedures effectively in a multithreaded Scheme system. That's why Gambit uses a distinct current-directory parameter object that can have a per Scheme thread binding and relative paths are interpreted relative to the Scheme thread's current-directory.
>
> The fundamental question is "what is SRFI 170 trying to achieve"? If the answer is "an interface to posix functions such as chdir, open, etc" then that is fine, but it shouldn't presume that there is a link between the posix open and the Scheme open-input-file, the posix relative paths and the Scheme relative paths, etc
>
> Anyway, in Gambit there is (path-normalize path) that can be called to turn the (possibly relative) path into an absolute path (using the current-directory parameter object if the path is relative), and the absolute path can be passed to the posix open in order to avoid being dependent on the process CWD.

Having a per-process CWD will of course work, strictly speaking, but
each thread may in principle change the CWD from underneath other
threads at any time.