Change:
Initial, Handshake, and the Short Header packets transmitted after the handshake belong to cryptographic and transport contexts.  The <del> Initial Completion fig-init-complete and the Handshake Completion fig-hs-complete datagrams finish these first two contexts, by sending the final acknowledgment and finishing the transmission of CRYPTO frames. </del> <ins> Client Completion fig-init-complete and the Server Completion fig-hs- complete datagrams finish these first two contexts, by sending the final acknowledgment and finishing the transmission of CRYPTO frames. </ins> <del> The Client Hello datagram exposes version number, source and </del> <ins> The Client Initial datagram exposes version number, source and </ins> destination connection IDs without encryption.  Information in the TLS Client Hello frame, including any TLS Server Name Indication (SNI) present, is obfuscated using the Initial secret.  Note that the location of PADDING is implementation-dependent, and PADDING frames might not appear in a coalesced Initial packet. <del> The Server Hello datagram also exposes version number, source and </del> <ins> The Server Initial datagram also exposes version number, source and </ins> destination connection IDs in the clear; information in the TLS Server Hello message is obfuscated using the Initial secret. <del> The Initial Completion datagram does not expose any additional </del> <ins> The Client Completion datagram does not expose any additional </ins> information; however, recognizing it can be used to determine that a handshake has completed (see sec-confirm), and for three-way handshake RTT estimation as in sec-rtt. <del> Similar to Initial Completion, Handshake Completion also exposes no </del> <ins> Similar to Client Completion, Server Completion also exposes no </ins> additional information; observing it serves only to determine that the handshake has completed. When the client uses 0-RTT connection resumption, 0-RTT data may also <del> be seen in the QUIC Client Hello datagram, as shown in fig-client- hello-0rtt. In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only present if necessary to increase the size of the datagram with 0RTT data to at least 1200 bytes.  Additional datagrams containing only 0-RTT protected long header packets may be sent from the client to the server after the Client Hello datagram, containing the rest of the 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first round is limited by the initial congestion window, </del> <ins> be seen in the Client Initial datagram, as shown in fig-client- initial-0rtt. In a 0-RTT Client Initial datagram, the PADDING frame is only present if necessary to increase the size of the datagram with 0RTT data to at least 1200 bytes.  Additional datagrams containing only 0-RTT protected long header packets may be sent from the client to the server after the Client Initial datagram, containing the rest of the 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first round is limited by the initial congestion window, </ins> typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). 2.5.

Discussion:
least four datagrams we'll call "QUIC Client Hello", "QUIC Server Hello", and "Initial Completion", and "Handshake Completion", for purposes of this illustration, as shown in {{fig-handshake}}. I mean, you can call them that for reference purposes, but there's no such thing as a "QUIC Client Hello" (or ClientHello). Calling something "Initial Completion" when it might not contain any Initial packets might confuse people when they go looking for more details. Maybe "Client Initial," "Server Initial," "Client Finished," and "Server Finished"? It mixes layers, but those are at least things that occur in the referenced packets.
Or, to avoid using TLS message names consistently, s/Finished/Confirmation
Should I conclude from the absence of comment since February that we are all reasonably content with "Client Initial", "Server Initial", "Client Completion", and "Server Completion"? If so I'm happy to create the PR to save Brian a job. But I don't want to do that if these are not the best names.
This was assigned to Brian has he wanted to take a stab.
That's fine I'll leave it to Brian.