> I am a bit shared. I understand that having proper "current working directory"
> based on parameter-like semantic, and having it per thread could be a good
> thing. But SRFI 170 is about "POSIX API", and I would expect the standard
> behaviour found in C world, where getcwd() is a per-process property

Simplicity is a good argument for a per-process CWD. However, some major
Scheme implementations already have a per-thread CWD that is used by the
RnRS procedures (among others) for interpreting pathnames. Having
different interpretation rules for the SRFI 170 procedures would
probably be confusing to users.

Would you consider it an acceptable compromise if the per-thread CWD can
be disabled via (parameterize ((working-directory #f)) ...) or similar?

> (but I didn't found formal definition of cwd as process property in Posix definition).

It's here:
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_447>

"3.447 Working Directory (or Current Working Directory)

A directory, associated with a process, that is used in pathname
resolution for pathnames that do not begin with a <slash> character."

> At minima, the direct reference about getcwd() and chdir() should be avoided,
> and the difference with them properly documented.

Absolutely. The current draft of SRFI 170 doesn't have a per-thread CWD
so the document doesn't talk about it yet.