Problem/Motivation
Meta issue: Drupal's nomenclature and code blurs the line between URIs and URLs in such a way that pretty much always assumes all URIs are URLs.
Example: The UriWidget provides a field widget for the uri entity field type. While the docblock on the field type references RFC 2616, this is actually the HTTP/1.1 spec; the applicable spec for URIs (of which URLs are a specific type) is RFC 3986.
Or, consider the case of simple_oauth (I'm the junior maintainer now) which adds a uri field on to the consumer entity for purposes of registering a redirect_uri value for OAuth 2.0. This value is often - but not always - a URL, but in the case of apps might look like my.app:/oauthredirect (a valid URI resolved by the phone's OS/middleware.)
In core, the core Link module has a uri property but stores only URLs and this makes sense in context.
(There are some internal URIs (e.g., internal://) that can be converted to URLs, and in this case the nomenclature is correct. E.g., Url::fromUri())
Proposed resolution
Clearly the 99% case here is that in practice URL == URI for most all users. However, this amounts to a bit of DX false advertising when a developer might reasonably assume that UriWidget accepts URIs. Consider however the url form element calls UrlHelper::isValid() for validation, which checks only a subset of RFC 3986. (It actually also broadens the validation to restirct to only http/https/feed.)
(It's worth noting this is some of the oldest code in Drupal; I traced the genesis of the inclusion of feed as a scheme to Dries in 2010!)
URLs and URL generation are important to web sites and this is definitely one area in which we have to consider BC. That said, it would also be good/appropriate for Drupal to treat URLs and URIs as per the spec and not create unnecessary developer WTF conditions when you really, actually want a URI.
There's no particular reason why developers who actually want to store a URI in a uri field can't change the element validation callbacks for the form element in an alter. I propose adding a validation function (most of the examples around the web speak to parsing, which is not necessary here) and also cleaning up a few of the more confusing docblocks that intermix URL and URI terminology.
Remaining tasks
Decide if this is a bigger issue we want to tackle (probably not/maybe only for Drupal 10?) and hone in on the DX components that are actionable and don't break BC.
User interface changes
None
API changes
None unless we want to tackle this e.g. by deprecating/renaming to be more consistent in Drupal 10.