> The idea I have about their current names is that they're simple Scheme
> style full versions of the POSIX call, opendir -> open-directory.

I sympathize with the desire to keep the correspondence between Scheme
and C names, other things equal. But as you say, the C names are very
old and hence may not be ideal.

I thought opendir() was much older than fchdir() and hence the dual
nature of pening directories was not taken into account there, but
interestingly both calls appeared in 4.2BSD.

In any case, I think open-directory as a name is still confusing
nowadays. To do things like "open a directory and then change to it",
you have to do `open` (or `open-file`) and then `set-working-directory`.
If you do the more obvious `open-directory` followed by
`set-working-directory`, that won't work. As it now stands, after
`open-directory` reading is the only thing you can do to it, whereas
after `open-file` you can do many more things to it.

> We *don't* currently support
> handing open-file the O_DIRECTORY enforcement flag (returns an error if
> you're not opening a directory), and I'm not at all sure this SRFI
> should support that, we'd have to do things like expose the dirent
> struct, which we current hide behind read-directory.

According to my understanding, O_DIRECTORY is entirely unrelated to
opendir() and readdir(). It's meant for use with fchdir() and the like.
Probably the libc opendir() implementation also uses it internally as an
extra safeguard to catch errors earlier, but that's an implementation
detail.

`struct dirent` is only returned from readdir() so I don't see any
scenario in which we'd need to expose it to users. It doesn't contain
anything useful other than the filename and filetype, and of those, only
the name is portable. So in practice, if you want more info on the file,
you need to follow up with a stat() family syscall anyway.

> Although that struct is boring, just the filename and "File serial
> number", i.e. inode.  We support reporting the inode with file-info,
> but don't otherwise provide anything about them.

True, it also provides the inode. And apparently it's guaranteed to be
there by Posix. I didn't know that.