Sorry for being a late-comer to this discussion, but I *staunchly*
oppose the entire "provide a thread-local current-directory API when
the system doesn't" approach:

- The standard should provide as thin layers around the operating
system as makes sense, and let users build their abstractions. Either
the abstractions can be built, in which case we should let the user
build them. Or they cannot be built, in which case the radioactive
mess of failure trying to build them should not be part of the
language.

- In particular, if the language does not allow the abstraction to be
built *as a library*, then the problem comes with the language's lack
of abstraction, not with its lack of primitives.

- If the operating system interface is completely broken (such as
inotify being unreliable or signals being lost), no amount of papering
over it can save the user, let alone provide them with a
one-size-fits-all solution with dealing with the issue.

- POSIX says that threads share current directory. RnRS should
acknowledge that, and anything else is bullshit. Don't break user
expectations with "magic" that is actually a curse.

- Using directory names is STUPID AND EVIL and chdir should NEVER,
EVER be used outside the user control. If you *HAVE* to do something,
use fchdir instead. There are ESSENTIAL CASES where the entire
"normalize to absolute path" makes NO SENSE WHATSOEVER: the process
may not have access to parent directories, hidden by a mount, by a
chroot, by a missing a unlink/unlinkat, by a missing permission or
capability, a renamed directory, a moved symlink, etc. Trying to
change directory by name is then completely broken and a huge security
vulnerability. Also, not all systems that you may run Scheme on may
have a functional fchdir.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
There are two kinds of problems with a tool: either it should do a
thing and doesn't, or it shouldn't do a
thing yet does. — Michael Raskin