Change:
the peer sends an ACK immediately when receiving a second ack- eliciting packet. <del> In order to accelerate loss recovery and reduce timeouts, the receiver SHOULD send an immediate ACK after it receives an out-of- order packet.  It could send immediate ACKs for in-order packets for a period of time that SHOULD NOT exceed 1/8 RTT unless more out-of- order packets arrive.  If every packet arrives out-of- order, then an immediate ACK SHOULD be sent for every received packet. Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events. As an optimization, a receiver MAY process multiple packets before sending any ACK frames in response.  In this case the receiver can determine whether an immediate or delayed acknowledgement should be generated after processing incoming packets. </del> <ins> In order to accelerate loss recovery and reduce timeouts, an endpoint SHOULD immediately send an ACK frame when it receives an out-of-order packet that is ACK-eliciting.  The endpoint MAY continue sending ACK frames immediately on each subsequently received packet, but the endpoint SHOULD return to acknowledging every other packet after a period of 1/8 x RTT, unless more ACK-eliciting packets are received out of order.  If every subsequent ACK-eliciting packet arrives out of order, then an ACK frame SHOULD be sent immediately for every received ACK-eliciting packet. If a packet is received with the ECN Congestion Experienced (CE) codepoint in the IP header, the endpoint SHOULD respond with an ACK frame immediately, even if the packet is received in order.  Doing so reduces the peer's response time to congestion events. If multiple packets are already available at an endpoint, the endpoint MAY process them all before sending an ACK frame in response.  The endpoint can determine whether an acknowledgement should be sent immediately or delayed after processing the batch. </ins> 4.1.

Discussion:
Yes, this was going to be my follow up question. Also NAME what about the ECN paragraph just below it?
NAME The current spec would not cause an ack to be triggered if non-ack-eliciting packets are received out of order. I think that's important. If the packet that was lost was another ack-only packet, this would cause unnecessary acks, and doing this at both ends could cause a minor ack storm. NAME out-of-order is defined in the draft above. I think it's less than ideal, but it's not ambiguous. NAME I've rephrased the ECN section just a bit to be clearer. Does that help?
I'll merge this. If folks have any pending questions, happy to take them on in a new PR.
What does it mean for a subsequent packet to arrive out of order? If I received packets 10, 11, 13, then clearly 13 is out of order. If I received 14 now, would that also be considered out of order? Would 15 be?This text is moving drafts in , so it might make sense to land that first? Or I I can pull this change in after it lands.What about the case where you receive an in order ack eliciting packet and then an out of order ack only packet? Should you still rely on delayed ack timer or send an ack immediately?