> How about a “current-directory” parameter object with
>
> (current-directory) => string
> (current-directory string)   ;; sets the current directory
>
> just like current-output-port, current-exception-handler, etc
>
> This has the advantage that each thread can manage their own current directory using “parameterize” to avoid interfeering with other threads
Some OSes do support having a different working directory for each
thread, but I'm not sure how portable that is. Also, for implementations
where the mapping between Scheme threads and OS threads is not 1:1, a
Scheme thread could switch between OS threads which could cause it to
unintentionally cycle between different working directories.

If you mean forgoing the OS concept of a working directory altogether,
and using our own Scheme parameter only, that would go against
convention so strongly (and would require vigilance in so many places)
that it sounds like a huge undertaking. Almost every Unix syscall
dealing with pathnames can take a relative pathname which it resolves
according to the OS process/thread working dir.

For applications, it may make sense to start building paths from a
thread-local working directory but would there be a simple way to do
that it in the SRFI? At face value it seems quite a drastic change from
convention.