>> * current-directory (per-thread parameter)
>> * os-current-directory (procedure - 0 args = getter, 1 arg = setter)
>>
>> * current-umask (per-thread parameter)
>> * os-[current-]umask (procedure - 0 args = getter, 1 arg = setter)
>
> This works for me, but while using argument count would keep the
> number of procedures the same, we're already using "set-*" as a convention
> for changing state.

It's true that set-* is more obvious, but parameter objects (SRFI 39)
work such that the setter is the same as the getter. Since there seems
to be agreement that the current directory should be implementable as a
thread-local parameter, using a unified getter/setter procedure would be
consistent with that.

> I don't see see any need to include "current" in the umask procedure
> names, current is implied, pretty much implied for all procedures like
> this.

Yeah, current-umask is a bit wordy. It would just be consistent with the
others. Perhaps the "current" is superfluous.

> I'm not sure about changing working-directory to
> current-directory, the underlying POSIX procedure wide call getcwd
> uses both....  Using both could be better, but if not that, I'd prefer
> keeping working-directory.

My argument is that all the other process/thread state stuff is called
"current". The working directory is the only one that is called a
"working" anything. (Does this imply everything else is "lazy"? :)

Current-working would be two words for the same thing. "Working" in Unix
doesn't refer to any other concept and is just a synonym for "current"
AFAIK. The only other thing I can think of is "working set" and that's
about CPU caches IIRC.

>> IMHO "umask" is a bit cryptic and not applicable outside Unix. Could it
>> be "unix-mask" instead, or simply "file-mask", "file-mode-mask",
>> "file-permission-mask" or something? What's the equivalent on Windows?
>
> Well, this is a *POSIX* API, and as you noted in other emails, there's
> no real mapping of POSIX's very simple permissions bits model to Windows.

True.

> Plus we'd expect some number of users of this API to already know
> "umask", and I don't think the u mapps to UNIX.

True as well. "u" probably means "user":
<https://unix.stackexchange.com/questions/583296/what-does-the-letter-u-mean-in-umask>.

But "unix" would make sense since the concept is only applicable under
Unix. Then again, John prefers "posix" instead of "unix". So it could be
"posix-mask" as well.

> The meaning of the
> bits is also inverted compared to the masks in file-info:mode and
> set-file-mode, a 1 in the umask means "no you can't" create a file
> with that bit, a 1 in the modes means "yes I am" set.
It's inverted precisely because it's a mask for those other ones :)