Original text:
Many RFC 7540 server implementations do not act on HTTP/2 priority signals.  Some instead favor custom server-driven schemes based on heuristics or other hints, such as resource content type or request <del> generation order.  For example, a server, with knowledge of the </del>  document structure, might want to prioritize the delivery of images that are critical to user experience above other images, but below the CSS files.  Since client trees vary, it is impossible for the

Reviewer comments:
and This is an editorial set of changes to the intro text. The first paragraph in the "motivation for replacement" section is actually broadly applicable motivation for any priority scheme. So we can move that up and highlight that H2 and H3 are multiplexed protocols that have the need of something. This helps us to clarify that mention of HTML document loading is only an example. We also give greater exposition about the actors involved in signalling, highlighting early that servers treat signals as a suggestion and they might follow some of the guidance provided later in the document.
To avoid bitrot, I'm merging.
The introductory material tries to be general, but routinely fails to be, falling back on talking about rendering web pages. If this is the best example, it could be more direct about that. Or, if this is general, it could try to be more careful about limiting its use of "document" and so forth to examples. For example, this lacks sufficient context: And this launches into talking about HTML without saying HTML:
good catch. I do think this is the best example and therefore will take your first suggestion. I'll follow up with a PR.
I have an unpushed branch for this that conflicts with other things, but I believe solves the matter.
says in part: In the first sentence, the endpoint is the one that is applying priority based on signals (or lack thereof) from its peer. In the second, the endpoint is the one providing signals when the peer is the one that acts upon it. This is confusing.
I see what you mean but I don't have a quick fix to hand. Would "one side operates in ignorance of the needs of the other" work?
Possibly. In the first you might say a sender might operate in ignorance of the needs of a receiver; the second might then say that a receive can communicate its view of priority to inform sender behaviour. Not that prioritization is exclusively about prioritization of sending, of course.
the terms in the second sentence were written intentionally fuzzy to accommodate intermediaries in the general statement. IIRC Robin elsewhere suggested just saying client and server but that risks over simplifying or misleading.
I think it might be a good idea to using terms "sender", "receiver", as suggested by NAME
To me, that risks conflating signal sender vs data sender. Someone want to propose a PR?

Revised text:
Many RFC 7540 server implementations do not act on HTTP/2 priority signals.  Some instead favor custom server-driven schemes based on heuristics or other hints, such as resource content type or request  <ins> generation order.  For example, a server, with knowledge of an HTML </ins> document structure, might want to prioritize the delivery of images that are critical to user experience above other images, but below the CSS files.  Since client trees vary, it is impossible for the