The thing that I rather dislike about this srfi (and here I'm speaking
of the draft right now on schemers.org) is the way in which it seems to
simultaneously be agnostic about operating system, and yet, at the same
time, incorporates at a deep level assumptions about what file names
are.

Notice that r5rs and r6rs filenames are simply strings.  Even that, on
some historic operating systems, is perhaps too much, but it's a
reasonable compromise.  But draft srfi 103 actually imposes the
assumption that these strings refer to hierarchically organized
filesystems of the vaguely Unixoid type.

This sort of file system organization was innovatively wonderful in the
seventies, when there were competing systems with a simple two- or
three-layer system.

So what srfi 103 assumes is that file names are hierarchically
organized, that these pathname components are separated by a *single*
os-dependent character, and so forth.  This is *way* too much.  It's
already too much to be mandating hierarchically organized files, but
this can't deal with the syntax of TOPS or VMS.  I'm not a great fan of
those systems, but surely we don't need to be further restrict the
possibilities.

We have here, as far as I can tell, more design-in-the-absence-of-use,
and this time, language design trying to mandate operating system design
principles.