You haven't given a convincing reason that there is a problem that needs fixing, or if there is, that your patch is the right way to fix it.

You have already pointed out that there is at least one scheme where :/// is part of a valid URL: "file:///". Where there is one, there could be others, if not today, then in the future:

    spam:///eggs.cheese

There are well over 200 registered schemes:

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

I don't think it will be practical to put in a whitelist or a blacklist of schemes that are, or aren't, permitted to include :/// after the scheme. It is the caller's responsibility to use the correct scheme, without adding extra characters to the end.

I asked you to justify why this should be considered a bug in the library, rather than a bug in your code. I'm not an expert on URLs, but the functions look correct to me. If you can't justify why this is a bug in the library that needs fixing, rather than user-error, we should close this or change it to a request for better documentation.