I have to agree, it seems there are some here with partial or minimal
understanding of the job that Eglot does and has done for a significant
user base for some years now.  We should allow these people some time to
become acquainted with Eglot, ideally via its actual use, before moving
on to architectural discussions.

At this point, I'd like to point out again that a manual for Eglot **exists
already**.  Written by Eglot's author (i.e. me), it is being rewritten
freely by Eli in Texinfo format, and this will become the "official
manual" to be published as frequently as possible.

The Texinfo manual, which I have already reviewed, is written in a
structured and sober style typical of quality Emacs manuals.  However,
the existing MANUAL.md which I have already linked to (and do it again
at the end), contains more contextual and historical information which I
shall migrate to commentary in the eglot.el source file.

For example, this section, which is not fully reproduced in the future
TexInfo manual, could shed some light on some of the issues being
discussed:

"Eglot uses LSP to activate modern IDE features in Emacs. These features
are
 provided via a number of auxiliary packages:

 * at-point documentation, via the ElDoc package;
 * on-the-fly diagnostic annotations with server-suggested fixes, via the
Flymake package;
 * definition chasing/cross-referencing, via the Xref package;
 * in-file symbolic navigation, via the Imenu package;
 * completion (via Emacs built-in front-ends, Company, or other front-ends)

[...]

Experienced users will notice that these auxiliary facilities aren't
exactly new in Emacs.  For lack of adequate configuration, they are
sometimes inactive by default.  Traditionally, each major-mode tries to
configure a subset of them, at least partially.  Users commonly fill in
the gaps in their personal configurations.  In general, it is
time-consuming to achieve some kind of unifying consistency across
different packages in the same major mode or across different major
modes in the same package.

This is the main problem solved by LSP and Eglot: Eglot links up Emacs
packages to LSP features (also known as LSP capabilities) by temporarily
configuring the auxiliary packages while it is active in some buffer
(see Eglot-managed buffers).

Not all servers support the full set of LSP capability, but most of them
support enough to enable the basic set of features enumerated
above. Conversely, some servers offer capability for which an Emacs
equivalent package doesn't yet exist, and so Eglot can't link up the
two.

There are some cases where Eglot itself offers a user-facing facility
for a given capability. Examples are the refactoring commands
eglot-rename and eglot-code-action-organize-imports (see Commands)."

The full MANUAL.md:
https://github.com/joaotavora/eglot/blob/master/MANUAL.md