And maybe also a Standards.URI.encoded_uri(void|string charset) which returns an encoded URI directly, to make it a little more convenient.
I take that you mean that it would _only_ encode non-ascii characters then? Because the way the API looks now, we have no way of knowing which characters are meant to be metacharacters unless we require that all metacharacters are already encoded in the input. I'm not entirely happy with the suggested name, it should be clearer that it mearly takes a partially encoded URL and encodes it some more (and exactly what gets encoded).
The thing is that when it comes to "/" inside path segments, at least 95% of all users don't want to bother with them at all, because there's no good way to handle them later on either. A partial decoding then does what the user wants for the input that the user wants to handle, without ambiguity, and the still-encoded slashes might very well be easier to deal with in higher layers (they can e.g. be stored in a filename in an ordinary file system). But a problem is that this approach also affects "%" which is a more sane char in ordinary paths.
Apart from the fact that you miss out on "%", x->path*"/" isn't all that inconvenient IMO. And it would allow you to use x->path*"\" on NT if you really want to. :)