Change:
6.4. <del> To correctly implement congestion control, a QUIC sender tracks every ack-eliciting packet until the packet is acknowledged or lost.  It is expected that implementations will be able to access this information by packet number and crypto context and store the per-packet fields (sent-packets-fields) for loss recovery and congestion control. After a packet is declared lost, it SHOULD be tracked for an amount of time comparable to the maximum expected packet reordering, such as 1 RTT.  This allows for detection of spurious retransmissions. Sent packets are tracked for each packet number space, and ACK processing only applies to a single space. 6.4.1. The packet number of the sent packet. A boolean that indicates whether a packet is ack-eliciting.  If true, it is expected that an acknowledgement will be received, though the peer could delay sending the ACK frame containing it by up to the MaxAckDelay. A boolean that indicates whether the packet counts towards bytes in flight. A boolean that indicates whether the packet contains cryptographic handshake messages critical to the completion of the QUIC handshake.  In this version of QUIC, this includes any packet with the long header that includes a CRYPTO frame. The number of bytes sent in the packet, not including UDP or IP overhead, but including QUIC framing overhead. The time the packet was sent. 6.5. 6.5.1. Constants used in loss recovery are based on a combination of RFCs, papers, and common practice.  Some may need to be changed or negotiated in order to better suit a variety of environments. Maximum reordering in packets before packet threshold loss detection considers a packet lost.  The RECOMMENDED value is 3. Maximum reordering in time before time threshold loss detection considers a packet lost.  Specified as an RTT multiplier.  The RECOMMENDED value is 9/8. Timer granularity.  This is a system-dependent value.  However, implementations SHOULD use a value no smaller than 1ms. The RTT used before an RTT sample is taken.  The RECOMMENDED value is 100ms. 6.5.2. Variables required to implement the congestion control mechanisms are described in this section. Multi-modal timer used for loss detection. The number of times all unacknowledged CRYPTO data has been retransmitted without receiving an ack. The number of times a PTO has been sent without receiving an ack. The time the most recent ack-eliciting packet was sent. The time the most recent crypto packet was sent. The packet number of the most recently sent packet. The largest packet number acknowledged in the packet number space so far. The most recent RTT measurement made when receiving an ack for a previously unacked packet. The smoothed RTT of the connection, computed as described in The RTT variance, computed as described in The minimum RTT seen in the connection, ignoring ack delay. The maximum amount of time by which the receiver intends to delay acknowledgments, in milliseconds.  The actual ack_delay in a received ACK frame may be larger due to late timers, reordering, or lost ACKs. The time at which the next packet will be considered lost based on exceeding the reordering window in time. An association of packet numbers to information about them. Described in detail above in tracking-sent-packets. 6.5.3. At the beginning of the connection, initialize the loss detection variables as follows: 6.5.4. After a packet is sent, information about the packet is stored.  The parameters to OnPacketSent are described in detail above in sent- packets-fields. Pseudocode for OnPacketSent follows: 6.5.5. When an ACK frame is received, it may newly acknowledge any number of packets. Pseudocode for OnAckReceived and UpdateRtt follow: 6.5.6. When a packet is acknowledged for the first time, the following OnPacketAcked function is called.  Note that a single ACK frame may newly acknowledge several packets.  OnPacketAcked must be called once for each of these newly acknowledged packets. OnPacketAcked takes one parameter, acked_packet, which is the struct detailed in sent-packets-fields. Pseudocode for OnPacketAcked follows: 6.5.7. QUIC loss detection uses a single timer for all timeout loss detection.  The duration of the timer is based on the timer's mode, which is set in the packet and timer events further below.  The function SetLossDetectionTimer defined below shows how the single timer is set. This algorithm may result in the timer being set in the past, particularly if timers wake up late.  Timers set in the past SHOULD fire immediately. Pseudocode for SetLossDetectionTimer follows: 6.5.8. When the loss detection timer expires, the timer's mode determines the action to be performed. Pseudocode for OnLossDetectionTimeout follows: 6.5.9. DetectLostPackets is called every time an ACK is received and operates on the sent_packets for that packet number space.  If the loss detection timer expires and the loss_time is set, the previous largest acknowledged packet is supplied. Pseudocode for DetectLostPackets follows: 6.6. </del> The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet. Exceptions follow.

Discussion:
This seems like an unwieldy PR, so I'll state what I've done. I've simply moved all pseudocode to the appendix with no changes to text, except for the addition of a single sentence at the beginning of the appendices. It might be easier to see the rendered draft . Subsequent PRs will clean each part up.
This is a good start. I expect some of the text in the pseudocode sections will need to move up, but one step at a time.