The biggest problem I see with this SRFI, to the point of crippling its adoption, is that it's so huge. So here are some suggestions about how to significantly decrease its size:

The removal of read-symlink eliminates the ability to round trip them, which makes all symlink awareness superfluous, including the option to not chase. This also helps with the reported 3 kinds of not quite as good symlinks Windows has.

These are even less justifiable than read-symlink per the 80/20 rule: user-login-name, file-info-regular?, file-info-block-special?, file-info-character-special?

file-info-socket? and system-name belong to a networking SRFI. current-timezone and current-locale make no sense just by themselves.

Every function that takes a filename and also a port and/or file descriptor should be scrutinized for dropping port and/or file descriptor under the 80/20 rule, and I think all of 3.6 User and group database access also fails that test.

The SRFI should be divided into a base, and break out into another SRFI everything pertaining to separate processes. At first glance I think that would move:

In 3.2 I/O, dup->fdes

In 3.3 File system, create-fifo

All of 3.4 Processes.

In 3.5 Process state, pid, parent-pid, process-group, set-process-group, and set-priority, and nice removes the process-object/pid argument, only affects the calling process. Not sure about the myriad get and set uid/gid; as I understand it, some are only relevant in the context of exec, but don't some set-uid or -gid program want to lower their privileges after starting?

All of 3.9 Signal system, which are signal-process and signal-process-group.

In 3.12 Terminal device control, I think open-control-tty, become-session-leader, tty-process-group, and set-tty-process-group.

- Harold