I don't want to derail de discussion, which seems interesting.
I just want to make a few points:
* Eglot catches `file://` URI references coming from the LSP server
and converts those -- and only those -- to file names. It uses
url-generic-parse for this. The function eglot--uri-to-path handles
a few more quirks but is not extraordinarily complex (about 15LOC).
* Eglot converts file names to URIs when it needs to tell the LSP
about the files it is managing. Here, too, conversion only happens
if the PATH argument is not already an URI, in which case nothing happens.
* This logic is fairly simple. Do you see anything to simplify in it, Michael?
Can `url-handlers` simplify the functions `eglot--uri-to-path` and
`eglot--path-to-uri`?
* I didn't mention that sometimes the "file names" are actually "trampish"
file names, depending on whether the M-x eglot command was invoked
in file being visited remotely by the TRAMP facility.
* The only thing that's outstanding in the discussion, as I follow it,
is that someone suggested that Eglot **warn the user** when the LSP
server communicates to us (Eglot) a URI scheme that is not known
by the current Emacs session, and as such `find-file` on it will fail.
* This is (or was) what Danny is asking for: A simple, robust way, for Eglot
code to ask the current Emacs session if this URI scheme is supported
downstream, and warn the user preemptively.
* If there's no excellent way to do the above, I think the code shouldn't
be changed. The user will eventually be confronted with the failure,
and once could argue that this moment is when she should be made
aware of the URI scheme that doesn't have a handler.
João