Change:
NAME NAME please take a look at the updated text!
Section 4.2.1 on delayed racing: "For example, if the first child represents an IP address with a known route, and the second child represents another IP address, the delay between starting the first and second IP addresses can be based on the expected retransmission cadence for the first child's connection (derived from historical round-trip-time). Alternatively, if the first child represents a branch on a Wi-Fi interface, and the second child represents a branch on an LTE interface, the delay should be based on the expected time in which the branch for the first interface would be able to establish a connection, based on link quality and historical round-trip-time." What the reasoning for these two recommendations? I'm actually not sure what exactly is meant. Is the first case 3xRTT (-> initial RTO) and the second 1xRTT? Why? Also in the next paragraph: "Generally, branches between paths and protocols should have longer delays than branches between derived endpoints." What? Why? And then "The maximum delay should be considered with regards to how long a user is expected to wait for the connection to complete." How do I know this?
Also, maybe it's just me, but I can't parse "retransmission cadence", and the phrase with "historical round-trip time" is 1) confusing (I don't get what it means, but maybe that's due to me misunderstanding "cadence"?), and 2) seems to be missing an article.
I read this as examples of things to consider when implementing a happy-eyeballs style algorithm, rather than explicit recommendations. Maybe this fix is to make this more vague, rather than more explicit?
I think NAME is right and the intention here is that these are just examples of things to consider. We should conclude if anything more is needed beyond making it more clear in the text that these are examples and fixing the other language issues.
The issue I agreed with was a desire to find simpler terms to describe these examples.
Refer to Happy Eyeballs for exact timing algorithm as the concrete reference (or ICE, etc).
It would be helpful to add some of the reasoning behind, e.g., "Generally, branches between paths and protocols should have longer delays than branches between derived endpoints."
Thanks, looks good. (Just marked a nit.)

Discussion:
initiated, or one of the child nodes successfully completes its negotiation. <del> Staggered racing attempts occur in parallel.  Implementations should not terminate an earlier child connection attempt upon starting a secondary child. The delay between starting child nodes should be based on the properties of the previously started child node.  For example, if the first child represents an IP address with a known route, and the second child represents another IP address, the delay between starting the first and second IP addresses can be based on the expected retransmission cadence for the first child's connection (derived from historical round-trip-time).  Alternatively, if the first child represents a branch on a Wi-Fi interface, and the second child represents a branch on an LTE interface, the delay should be based on the expected time in which the branch for the first interface would be able to establish a connection, based on link quality and historical round-trip-time. Any delay should have a defined minimum and maximum value based on the branch type.  Generally, branches between paths and protocols should have longer delays than branches between derived endpoints. The maximum delay should be considered with regards to how long a user is expected to wait for the connection to complete. If a child node fails to connect before the delay timer has fired for the next child, the next child should be started immediately. </del> <ins> Staggered racing attempts can proceed in parallel.  Implementations should not terminate an earlier child connection attempt upon starting a secondary child. If a child node fails to connect before the delay time has expired for the next child, the next child should be started immediately. Staggered racing between IP addresses for a generic Connection should follow the Happy Eyeballs algorithm described in RFC8305.  RFC8421 provides guidance for racing when performing Interactive Connectivity Establishment (ICE). Generally, the delay before starting a given child node ought to be based on the length of time the previously started child node is expected to take before it succeeds or makes progress in connection establishment.  Algorithms like Happy Eyeballs choose a delay based on how long the transport connection handshake is expected to take. When performing staggered races in multiple branch types (such as racing between network interfaces, and then racing between IP addresses), a longer delay may be chosen for some branch types.  For example, when racing between network interfaces, the delay should also take into account the amount of time it takes to prepare the network interface (such as radio association) and name resolution over that interface, in addition to the delay that would be added for a single transport connection handshake. Since the staggered delay can be chosen based on dynamic information, such as predicted round-trip time, implementations should define upper and lower bounds for delay times.  These bounds are implementation-specific, and may differ based on which branch type is being used. </ins> 4.2.3.