/.../ But why would this be better than
path = map (path_segments, encode) * "/";where encode does all the job?
Because, again, before the encoded_uri() step it's a valid IRI which needs no further encoding.
Well, it depends on the context if this is the right thing to do or not, of course. If the encoded and unencoded /:s actually need to be handled differently in the application, then the user needs to do something anyway.
Well, the different handling of that particular char in a path is mandated by RFC 3986 if the URI is hierarchical. The application can't choose to not differentiate in that case (except, of course, if it chooses to not conform to the URI standard). For other reserved chars it can make that choice, though.
If that something is simply to complain, then
Array.sum(map(path, has_value, "/"));
would do as a simple test.
That's not simple for applications that don't want to handle it. For them it's simpler if the path splitter function in Standards.URI throws an error, just like it does on other malformed URI:s.
Depending on the situation there are other characters than "/" that you might want to treat specially. "\" for example, would introduce exactly the same ambiguity that you refer to if running on an NT system.
Can't see how it would, since it can never occur unencoded in a URI or IRI. If that happens then the URI is invalid, and I think the best way to handle that is to treat it as if it was encoded (i.e. just leave it as it is during %-decoding).
So simply leaving "/" encoded does not really solve that problem.
I never said it does, I only said that in some cases it can be enough.