John, inspired by the C++ <filesystem> header, and I have been discussing adding this to SRFI for the purposes of finding out how much space is left on a file system.
But it's not quite that simple, for the rules are different for a normal user and root.
I think it's better to ignore that. Root shouldn't step on the extra space either, not to mention the purpose of R7RS-large is application development, and applications shouldn't run as root.
I'm not going to think hard before I make a minimal implementation, but I'd personally like everything but I suppose f_fsid file system id; and if we include everything else, might as well include it.
File system id, maybe, but again, does that meet the 80/20-for-applications standard? Then there's the remaining number of "file serial numbers", which is Posix for inodes: theoretically you could overflow that if your disk is tiny or you open millions of little files. But in the latter case you probably want a database nowadays anyway.
And I note f_blocks, total number of blocks on the filesystem can hint at the purpose of a file system.
I think that's very unreliable and we shouldn't go there.
Running out of disk space, on the other hand, is still a dead serious concern for applications, which is why I proposed the Simplest Possible Thing, namely file-space (for a path when you are going to create a new file, or a port if you are trying to guess if an open file will run out of space) which returns the value in bytes. This way we need no new object type, no new set of accessors, etc. etc.