Code change:
Created a separate issue to discuss ECN.
The guideline section discusses "Investigating a Range of Environments", with a focus especially on "Random Early Detection (RED) ] and Drop-Tail." The IETF and the IRTF have produced several different proposals for Active Queue management, with somewhat different characteristics. Interestingly, there is a tension there between developing Queue Management that "plays well" with existing congestion control algorithms, and developing congestion control algorithms that "take advantage" of AQM. Not sure what to say there, but at a minimum we should develop expectations about "signals" produced by AQM (e.g., the ECN markings of L4S) and reaction by congestion control algorithms. To go further, the could be a discussion of "honest signals", such as delays, that are very hard to "fake" in routing nodes, other signals such as ECN marks that could be produced by the network at very little cost, and packet losses that fall kind of in between. But we are not writing for the IRTF, so this could be kept brief.
On the topic of AQM, IETF published Characterization Guidelines (RFC7928) and Recommendations (RFC7567) that could be exploited for further discussions in this work.
Martin and Gorry: add a reference to 7567 to AQM behavior and evaluation criteria, which is not in scope for this document talk about evaluating CC interaction with AQM
Something like "CCs should be evaluated against AQMs that are prevalent in the internet" -- is there a reference that provides a taxonomy?
Editors: FQ-CoDel, PIE, L4S (RFC9332) have RFCs Are the others that should be evaluated, and do they have available specs?
Discussed at IETF 118: Many operators are not particularly aware of AQM or these concepts in general Include FIFO in the list Also do at least an AQM "you should evaluate the scenario with FIFO queues and should also consider the impact of various common AQMs and run detailed simulations against them", while maybe name-checking a few particularly relevant ones. Yes, should have criteria for this, and also should not ask people to run NxN interop matrix. Out of scope to mandate AQM
I suggest: Probably ought to include a suitably configured RED also. ... and not suggest ALL of these need to be checked, more encourage consider AQM and FIFO scenarios.
I fixed a typo, but otherwise this looks good.

Related discussion:
text: 5.1. <del> (TODO: Write this section) </del> <ins> Proposals SHOULD be evaluated under a variety of bottleneck queue disciplines.  At a minimum, a proposal should reason about an algorithm's response to various AQMs.  Simulation or empirical results are, of course, valuable. Note that evaluation of AQM techniques - as opposed to their impact on specific congestion control proposals - is out of scope of this document.  RFC7567 describes design considerations for AQMs. Among the AQM techniques that might have an impact on a congestion control algorithm are FQ-CoDel RFC8290; Proportional Integral Controller Enhanced (PIE) RFC8033; and Low Latency, Low Loss, and Scalable Throughput (L4S) RFC9332. </ins> 5.2. <ins> (TODO: Write this section) 5.3. </ins> Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth products RFC3649. <del> 5.3. </del> <ins> 5.4. </ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.