Change:
URL here, I propose to rewrite the first part of the paragraph so that it is easy to read. for example - Packets in the handshake belong to three separate cryptographic and transport contexts - "Initial", which contains observable payload, "Handshake", which is not observable "1-RTT", which is not observable Here we are repeating stuffs from RFC9000 without referring to them but I found the figure in RFC9000 more explanatory. why are we rewriting it here instead of just referring to RFC9000 ?
I think it is important to have a figure in this document as reader of this document are not necessarily willing to read RFC9000. Thus this document should be useful as a stand-alone read. The figure in this document is meant to be a simplification compared to the one in RFC900 there it is omitting some of the less relevant details, e.g that there is an initial and a handshake packet.
Also disagree that the diagram in RFC9000 is better for the purposes of this document; would prefer to keep it. The paragraph is a bit difficult to read, though, reflecting the history of this section more than what we actually want to say. Will propose a reordering/simplification...
Ok, I think I understand why you want to keep the figure. I actually had to look at the RFC9000 to understand it better. I hope the promised reordering would help here.

Discussion:
Initial", "Client Completion", and "Server Completion", in the illustration shown in fig-handshake. <del> Packets in the handshake belong to three separate cryptographic and transport contexts ("Initial", which contains observable payload, and "Handshake" and "1-RTT", which do not).  QUIC packets in separate contexts during the handshake can be coalesced (see coalesced) in order to reduce the number of UDP datagrams sent during the handshake.  QUIC packets can be lost and reordered, so packets within a flight might not be sent close in time, though the sequence of the flights will not change, because one flight depends upon the peer's previous flight. As shown here, the client can send 0-RTT data as soon as it has sent its Client Hello, and the server can send 1-RTT data as soon as it has sent its Server Hello. </del> A handshake starts with the client sending one or more datagrams <del> containing Initial packets as shown in fig-client-initial, which elicits the Server Initial response as shown in fig-server-initial </del> <ins> containing Initial packets, detailed fig-client-initial, which elicits the Server Initial response detailed in fig-server-initial </ins> typically containing three types of packets: Initial packet(s) with the beginning of the server's side of the TLS handshake, Handshake packet(s) with the rest of the server's portion of the TLS handshake, and 1-RTT packet(s), if present. <del> The Client Completion flight contains at least one Handshake packet and could also include an Initial packet. </del> <ins> As shown here, the client can send 0-RTT data as soon as it has sent its Client Hello, and the server can send 1-RTT data as soon as it has sent its Server Hello.  The Client Completion flight contains at least one Handshake packet and could also include an Initial packet. QUIC packets in separate contexts during the handshake can be coalesced (see coalesced) in order to reduce the number of UDP datagrams sent during the handshake.  QUIC packets can be lost and reordered, so packets within a flight might not be sent close in time, though the sequence of the flights will not change, because one flight depends upon the peer's previous flight. </ins> Datagrams that contain an Initial packet (Client Initial, Server Initial, and some Client Completion) contain at least 1200 octets of