Lassi posted a query to srfi-discuss about a standardized interface to operating system functions, and I replied privately that I had just sent in SRFI 170 for srfi-editor review.  This email is excerpts from the conversation we had, with explicit permission from Lassi to publish it.  A lot of marginally relevant non-technical stuff has been left out.   I'm putting everything about terminals in another email to keep this one shorter.

LK: What's the attitude among those of you who have already designed and discussed this - how finished do you feel the current design is, do you mostly want to get it done and out the door, or do you welcome significant changes? How big a userbase does scsh have currently and would they be disrupted if many things were different?

JC: Well, if the changes are too large, then scsh can no longer count as an implementation, and someone (definitely not me) would have to write another implementation on top of some Scheme.  Right now,
I think the list of exceptions and deviations is short enough, and each one is simple enough, not to be too concerned.  [A different conversation with Arthur Gleckler encouraged me to move somewhat further away from Scsh than this would suggest.]

LK: I'll gladly assist with making the API Windows-compatible and do a reference implementation for some Scheme that runs there.  [JC is very glad to hear that.]

I also have many suggestions (backed by significant experience) for the Unix side, but I'll have to think for a bit about many of them. 

The big differences on Windows [LK mentioned others] are no fork() and no exec().   [I replied to this by proposing to add spawn-* calls, and Lassi agreed.  Scsh doesn't have them but they would be easy to add.]

LK: Many things could be improved about Python's API as well. But where it shines is in humility. They don't try to layer too much magic on top of the Unix API functions and their arguments. And they try to support everything, within reason. That principle is a good foundation for this kind of work. As for the details, they are art, not science.  [JC agreed that Python does a decent job, and is now raiding it for stuff to add, cautiously, to SRFI 170.  We can always put in more later; we can't take things out.]

LK: Python 3 chose to use strings to pass filenames and got in trouble. They later had to amend things so bytevectors can be passed instead of strings (e.g. if you pass the pathname to os.listdir() as a bytevector then it gives bytevectors back also). Otherwise you get in trouble with weird filenames since most filesystems don't normalize filenames into any particular character encoding or normalization form.  [JC pushed back on this stupidity, but concedes that something like it may be necessary.  Fortunately Python has done most of the legwork.]

John Cowan
Almost all theorems are true, but almost all proofs have bugs.
        --Paul Pedersen