I will open a separate bug for that.

So if python-mode is taking around a hundred thousand times (!) more to
compute that piece of information for some buffer positions, I'd say
it's definitely something to look at...

From a quick check it seems indeed that the time it takes to compute it
is proportional to the value of point the buffer. Suggest creating a
bug for python-mode, or calling in whoever wrote that part.

I agree it's suboptimal for python-mode to be so (intermittently) slow at computing end-of-thing. It's certainly an issue worth solving, but not the main issue IMO.

The main issue is that eglot is trying to "correct" a region using data which is already outdated, and therefore not likely to result in anything useful, however hard flymake tries.

Eglot could detect off-by-one diagnostics
+++++++++++++++++++++++++++++++

Hard to know the best heuristic, but lots of null effective ranges is
a good one.

Eglot can simply ignore null range diagnostics
+++++++++++++++++++++++++++++++++++

Eglot doesn't need to use `flymake-diag-region' to try to calculate an update range if it encounters a null
diagnostic range. It could simply drop those, as they are probably wrong anyway, and will shortly be updated.

Maybe, IF we can confidently say that the server is in the wrong.

But I added it there for a reason, and quite a long time ago. See the
commit log for

commit 7826b265a0ecd9357719b2fb9491c9bcb517d4cc
Author: João Távora <joaotavora@gmail.com>
Date: Thu Jun 21 23:32:14 2018 +0100

I'm moderately sure someone somewhere expects the botches ranges to be
auto-corrected by Eglot (though admittedly not at the expense of large
delays).

It appears from that commit message that the issue is rather that certain servers send null ranges up front. One middle ground here would then be to attempt to correct ranges only if they start out null from the server, not if they are collapsed that way by eglot. Implementing this makes performance not that great, but predictable: no 10s pauses.

/**
* Optional the version number of the document the diagnostics are published
* for.
*
* @since 3.15.0
*/
version?: integer;

It seems eglot keeps track of the "document version" in `eglot--versioned-identifier'. I believe that can be compared to the one in the `textDocument/diagnostic' message to avoid this mess altogether.

See attached patch for both of these options rolled together; this has performance which is now actually quite decent in my long file. It drops the outdated push diagnostics of my chatty server, which seem to be about half of them. Not only does this eliminate the "off by one" catastrophic flymake issue, it improves performance overall significantly, probably due to less flymake overlay churn.