> 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:

Thank you for commenting.

> - The standard should provide as thin layers around the operating
> system as makes sense, and let users build their abstractions.

It's not yet clear whether this is going into standard Scheme
(R7RS-large) or staying as an individual SRFI.

> Either the abstractions can be built, in which case we should let the user
> build them.

The logical conclusion is that the language would end up with nothing
save for `lambda` and friends.

For example, SRFI 1 (List library) could be built from simpler parts but
there would be no sense in everyone reinventing the wheel.

> Or they cannot be built, in which case the radioactive
> mess of failure trying to build them should not be part of the
> language.

If leaky abstractions may never be built, we need to give up on Scheme
and go build with assembler or logic gates or something. A measure of
pragmatism is required to deal with software (or indeed, life itself).

> - 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.

Isn't the big idea of Lisp to blur the distinction between languages and
libraries? A big Lisp dialect is a small core plus lots of useful
libraries. Even core Haskell looks like typed Lisp so arguably the
syntactic sugar is library code.

Mending Scheme's core abstractions to conform to Posix sounds like the
language design equivalent of what they call overfitting in ML. Lisp has
survived for decades because aversion to overfitting is a fundamental
tenet of Lisp culture.

> - 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.

Agreed. There have been problems with previous attempts to match Scheme
ports 1:1 to Unix file descriptors, maintaining the correspondence in
all circumstances. It's very hard and still doesn't really work.
> - 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.

That's the POSIX current directory. It has been argued extensively on
the SRFI 170 mailing list (especially by Marc from Gambit and Per from
Kawa) that the notion is troublesome for multi-threaded Scheme code.

> - 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.

Here you raise good points. Opening the current directory and using
fchdir() in the parameter converter may make sense. As you say, it may
still break and will certainly be non-ideal. But it's not clear that
Unix affords an ideal solution no matter what we do.