>     If the implementation has a custom 'path' datatype, it
>     should be passable to any OS procedure that takes a path argument.

> I don't agree there.  I originally had a SHOULD that said SRFI 170 implementors should make their standard Scheme I/O procedures accept both ports and fds.

> Similarly, there are conversions in SRFI 170 from fds to ports, and you can use them with Scheme read or display or what not.

It should be noted that the port-vs-fd distinction is drastically
different from the path-object-vs-path-string distinction. Ports and fds
_embody_ OS-level objects. Paths just _tell you where you can find_
OS-level objects if you want them. So ports and fds have complex
lifetime and ownership issues that paths don't have (because a path does
not guarantee you can find something at that path in the future).

I 100% agree that ports and fds should not just be implicitly converted
into each other.

> But it really doesn't gain anything over the monomorphic approach.

The thing it gains is convenience in an implementation where people
shuffle path objects around all the time.

> If you have a path datatype, there will be one or more converters to string, and you can just call those.

But is there harm in auto-converting a path object to a path string? I
can't think of any but I'm not experienced with this topic. Is there not
usually a "canonical" way to convert a path to a string, and if there
are several conversion rules, is there a concern that some of them won't
work or we should pick a different rule in different situations?