Well, one could argue that it'd help people pick the right one and
How so? If there is only one, then that one is always the right one.
realize that they actually aren't using URIs anymore if they go outside US-ASCII, which probably is a widespread misconception.
Since the IRIs can be mapped to URIs, they can be made to actually use URIs without them having to realize.
But there would also be practical differences:
o An IRI class can decode the utf-8 sequences, which an URI class can't. (More precisely, it must do this precisely in the transformation from an URI.)
When must one transform from an URI then? Using the URI representation seems more powerful since it can represent both URIs and IRIs.
Of course, having a function to decode the utf-8 sequences is something we want, but this should be possible (and done in the same way) regardless of whether you start with an IRI or an IRI mapped into an URI, IMO.
o An IRI class doesn't necessarily have to do the transformation to URI since an IRI can contain wide chars in unencoded form. I.e. it should be able to put together and pick apart the IRI syntax with 8 bit and wider chars on both sides.
No, but I don't think the performance issue warrants a confusing split in the namespace. Whether the "picked apart" pieces contain wider chars or not seems irrelevant since you need to decode it anyway (%25, %2f). The decoding should give you wide chars regardless of whether you start with an IRI or an IRI mapped into an IRI (see above).
o As for the encoding side, extending the URI class to automatically do an IRI-to-URI conversion for wider chars is safe from a standards perspective (i.e. it wouldn't break the URI standard). But in practice it wouldn't be strictly compatible since Standards.URI currently treats 8-bit chars differently.
Yes, but that is a bug, AFAICT, just as http_encode_string() is currently bugged. The behaviour we'd be removing is wrong, from a standards point of view, so removing it from the Standards module seems the right thing to do.