Thank you to both of you for the continued hard work on the drafts!

> I renamed `tty?` to `terminal?`.  As of now, there are no instances of
> "tty" in the SRFI except in the command `stty` and the names of Posix
> functions.  In DEC OSes, device names couldn't be more than three
> letters long, but that's long dead.

Good call.

Windows also has vestigial CON devices ("console"). I don't know if
they're used for anything anymore (the CON filenames are just reserved).

> I have concluded that control of symlinks does meet the 80-20
> limitation, especially as implementation is trivial.  So I have added
> back `create-symlink`, `read-symlink`, and `file-info-symlink?`.

Nice. Have to investigate what to do on Windows, which has 3-4 flavors
of variously broken symlinks :)

> I've also merged hga up to date.  Unless there are major objections to
> the substantive changes, I'll do a PR for Arthur (it'll take him a while
> to get to it; he's swamped).

I like the way it's going. Just noticed that the directory and timespec
objects/procedures are specified makes it possible to use them with
directory ports and opaque time objects as in Gambit. That's great.

Minor nits:

* I would talk about "named pipes" instead of FIFOs. Everyone knows
ordinary (anonymous) pipes, so by emphasizing that FIFOs are just a
named variant of the same, there are fewer words for the same thing.
Windows API documentation also talks about "named pipes"
(https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipes). So the
procedures would be create-named-pipe and file-info-pipe?.

* (BTW: we don't have a pipe() procedure?)

* The following stat fields are obscure and rarely used:
(file-info:device file-info)    →    integer       (procedure)
(file-info:inode file-info)    →    integer       (procedure)
(file-info:nlinks file-info)    →    integer       (procedure)
(file-info:rdev file-info)    →    integer       (procedure)
(file-info:blksize file-info)    →    integer       (procedure)
(file-info:blocks file-info)    →    integer       (procedure)

device and inode are good to have for file uniqueness checking, but
should we instead provide an OS-dependent uniqueness identifier (which
on Unix can be a (device . inode) cons cell)?

nlinks is the number of hard links. Harold, do you have a use case for
this in your backup program?

rdev is the device type. What does that mean - are these device numbers
used internally by the kernel?

blksize and blocks are nowadays-obscure details of the file system
implementation. The most likely use for these is using them by accident
instead of file-info:size.

* directory-files -- would be clearer to call it "directory-names" for
two reasons: 1) it's not clear whether it returns full paths or only the
basename parts; "names" emphasizes that it's the basenames only. 2)
"files" suggests regular files only; this is a meaningful distinction in
some Common Lisp implementations. "names" is clearer that it returns all
names in the directory, not just regular files.

* I still think dotfiles? is arbitrary, and it's misleading that the
default is false, but it's your call. I would leave dotfile filtering to
higher-level code such as a (glob) procedure or a (ls) user interface.
On Windows, dotfiles are not the canonical way to indicate hidden files;
there is a "hidden" flag in the FAT/NTFS file attributes.

* Could 'delete-directory' be called 'delete-empty-directory' for extra
clarity? A 'delete-directory-tree' procedure would be useful in a higher
level library. When both exist, the distinction is not obvious unless
the names are explicit.

* call-with-temporary-filename has "temporary" in the name; all the
other tempfile definitions just say "temp".

* (read-symlink fname [override?]) -- the override argument is included
here by mistake.