Btw, maybe Standards.URI()->http_encode should be fixed at the same time? It doesn't seem to encode wide characters at all, and encodes 8-bit characters as %XX (iso-8859-1).
I think me and Johan Schön chickened out when making Standards.URI and only aimed for the basic principle of taking URI:s apart and putting them together again, without losing data or precision. The latter is a bug, especially today, and probably ought to be fixed with prior utf-8 encoding.
I would very much welcome an improved variant with getters and setters doing automatic encode/decode translation, perhaps in the form of a Standards.URL, where such behaviours are more well defined (especially for schemes http, https, ftp, ftps and maybe a few others) than for the generic case of URIs, or abominations like the javascript: scheme.
Doing it in the form of an inheriting Standards.URL would have a bonus benefit of not fscking up prior code. In practice you rarely have URIs that are not URLs too, anyway, so getting a kick-ass Standards.URL for such matters would be an improvement, and afford more useful defaults.
For tinkering with the URI parts, setting and getting them raw, the low level Standards.URI could stay mostly as is, while most API users would instead adopt tools better equipped for playing with URLs.