I have a new patch attached that does what João suggested in the 5 point 
list,
which I will respond to again

 > 2. Eglot converts the URI X into a some file designator Y, using
 >    eglot--uri-to-path.  Y may or may not be === X, as long as there is
 >    exactly one X for every Y.  Eglot makes xref-item objects from it
 >    using xref-make-match and xref-make-file-location.  The designator Y
 >    goes into the 'file' slot of the xref-file-location object.

The patch leaves X === Y for `jar` type URIs. My updated packages now 
deals with
the full jar URIs. No conversion are done. My new package can be found here:
https://git.sr.ht/~dannyfreeman/jarchive/tree/9148ed7ada03ff2516f6e4ede20c453974d6da19/item/jarchive.el

 > 4. B2 can be setup in a way so that project-current returns the same
 >    object which is returned in B.  If this is true,
 >    eglot--current-server discovers the same connection which also
 >    manages B1 and Eglot adds buffer B2 to the list of managed buffers in
 >    that connection.
 >
 >    However, if eglot-extend-to-xref is non-nil, eglot--current-server
 >    should also discover the correct connection.  This is less ideal than
 >    making project-current know that the buffers of source code inside
 >    the jar are also in the same project, but it works.  I can explain
 >    the downsides, but it's not very relevant right now.

My newly updated package does nothing with `project-current`, as I have no
obvious way to access the previous project when extracting files from 
the jar.
(Extracting now happens in `insert-file-contents` instead of 
`get-file-buffer`)

BUT eglot-extend-to-xref works as it should with this, and I think I 
prefer that.
It allows people who don't want that behavior to disable 
`eglot-extend-to-xref`
and have eglot start up a new lsp server when visiting the file.
Idk why anyone would want that but you never know.

 > 5. Upon findin the "file", Eglot transmits a :textDocument/didOpen
 >    notification to the server.  This requires eglot--path-to-uri, the
 >    reciprocal of eglot--uri-to-path to convert the path Y to URI X
 >    again.  Again, maybe this conversion is just #'identity.
 >
 >    Eventually, the LSP server knows that the client is now working on a
 >    textDocument whose relationship to other opened documents in the
 >    workspace it understands (which may or may not be read-only).

Sending the full jar uri back to the lsp server worked exactly as 
intended here.
I am honestly surprised I didn't have to change anything in clojure-lsp. 
It can
do it's analysis on the file without issue.

 > 6. xref-find-definition on any part of the B2 should now work similarly
 >    to this whole flow.

It does!!!!!

As for this question

 > I don't know what happens if another server also points to the same file.
 > Probably nothing very bad, but there may be some suprising behavior: I
 > haven't tested.

The same file continues to work with respect to the original lsp server
that was used to open it. The second lsp server is not conidered. I
guess because eglot can only work with one lsp server at a time. If you 
want to
associate the un-jar'd file with the second server, close it and
xref-find-defintions to it from a file in the second server. That seems 
like a
fine workaround to me, and its not something I've ever encountered in my 
routine
development workflow.


So, what do yall think about the patch? Is that something you might 
consider for
eglot? I believe I could also accomplish something similar with "advice" 
in my
package and leave eglot alone, but I would be poking at eglot internals 
which
seems not ideal.