I ran a git bisect and found that commit
0ff82eb48725e15bb87a75d4f937b75c2482c59b appears to be the first commit
to exhibit this behavior, although I'm not entirely sure why.  It was a
fix for bug #69809.

My understanding is this: every time flymake recomputes diagnostics
(e.g. on file save), it queries all of the backends in
`flymake-diagnostic-functions' to get new diagnostics.  When it gets new
diagnostics from a backend, it goes through the buffer, removes all the
existing diagnostics produced by that backend, and inserts the new
diagnostics that it just got.

Before running eglot, `flymake-diagnostic-functions' is equal to
(rust-ts-flymake t) (I'm not sure what the significance of the t is).

When you start eglot, this line in `eglot--managed-mode' replaces the
value of flymake-diagnostic-functions:
(eglot--setq-saving flymake-diagnostic-functions '(eglot-flymake-backend))
Then it has flymake refresh its diagnostics.  Since rust-ts-flymake is
no longer in flymake-diagnostic-functions, flymake doesn't request any
new diagnostics from it.  But since flymake only deletes the existing
overlays for a diagnostics backend when that backend provides new
diagnostics, those diagnostics never get removed.

The attached patch fixes this by adding code to flymake-start which goes
through flymake--state and removes all diagnostics and their overlays
from any backend which is no longer in flymake-diagnostic-functions.

I also noticed a related (but less serious) bug here: after opening a
rust buffer, running rust-ts-mode, then eglot, if you stop eglot with
eglot-shutdown or something, all the eglot diagnostics in the buffer are
removed, but the rust-ts-flymake diagnostics don't come back until you
do something to trigger flymake-start (like save the buffer).

Eason Huang <aqua0210@foxmail.com> writes:

> I find out that it is related to `rust-ts-flymake-command`, when
> customize it's value to `'("cargo" "clippy")`, it works as expected.
>
> It works with below rust config:
>
> ```
> (use-package rust-mode
>   :defer t
>   :custom
>   (rust-mode-treesitter-derive (and (fboundp 'treesit-available-p)
>                                     (treesit-available-p)))
>   (rust-ts-flymake-command '("cargo" "clippy")))
>
> ```
>
> May be this information help.

This gets rid of the initial errors from rust-ts-flymake, which may be
spurrious.  I'm not sure.  Maybe this should be the default for
rust-ts-flymake-command?  Either way, I think a patch like what I've
written is necessary to solve this general problem.