> My point is that if the current working directory (per process of per
> thread) can currently only be changed for single-threaded programs,
> SRFI 170 should provide some mechanism for multi-threaded programs as
> well. I don't mind if it is at a higher abstraction (at the thread
> level, for example) than in POSIX (although it is probably easier to
> first provide the raw C interface first and then some sophisticated
> abstraction on top of it).

Sorry, I misunderstood what you were after. Implementing
`current-directory` as a parameter is a proven way to do what you
suggest for multi-threaded programs.

I anticipate that if we give both a low-level procedure and a high-level
procedure in the same SRFI, it can give the impression that we encourage
the low-level one to be used as an equally good alternative to the
high-level one, whereas it would be better to discourage people from
reaching for low-level procedures for general usage. Lots of
programmers, even good ones, have the instinct to "optimize" things that
would be better left unoptimized.

If decidedly low-level stuff goes into distinct low-level SRFIs that are
clearly advertised as such, that puts up a slightly stronger mental
barrier and lets people know what they are getting into.