Change:
After decryption, the client's Initial packet can be parsed to detect the CRYPTO frame(s) that contains the TLS ClientHello, which then can <del> be parsed similarly to TLS over TCP connections.  The client's Initial packet may contain other frames, so the first bytes of each frame need to be checked to identify the frame type, and if needed skip over it.  Note that the length of the frames is dependent on the frame type.  In QUIC version 1, the packet is expected to contain only CRYPTO frames and optionally PADDING frames.  PADDING frames, each consisting of a single zero byte, may occur before, after, or between CRYPTO frames.  There might be multiple CRYPTO frames. Finally, an extension might define additional frame types which could be present. </del> <ins> be parsed similarly to TLS over TCP connections.  Note that there can be multiple CRYPTO frames, and they might not be in order, so reassembling the CRYPTO stream by parsing offsets and lengths is required.  Further, the client's Initial packet may contain other frames, so the first bytes of each frame need to be checked to identify the frame type, and if needed skipped over it.  Note that the length of the frames is dependent on the frame type; see Section 18 of QUIC-TRANSPORT.  E.g.  PADDING frames, each consisting of a single zero byte, may occur before, after, or between CRYPTO frames.  However, extensions might define additional frame types.  If an unknown frame type is encountered, it is impossible to know the length of that frame which prevents skipping over it, and therefore parsing fails. </ins> 3.5.

Discussion:
I think there are still a few potentially misleading statements left in the text. I'll send out a PR.
The mentions . This makes the assumption that INITIAL packets carry a single CRYPTO frame. That assumption might not always hold in modern browsers, so the text should clarify that any middlebox that wishes to extract the SNI MUST perform reconstruction of the crypto stream from one or more CRYPTO frames in one or more INITIAL packets. The current assumption might lead middlebox vendors to write deploy software that doesn't work if there are multiple CRYPTO frames. The section correctly states but that comes late in the section and doesn't detail what middlebox vendors should do about it. That section also contains another incorrect assumption: . There are other frame types that are legal in INITIAL packets and may be sent by browsers.
I think this is pretty similar to , though that one is a bit more broad. Thanks for noticing the statement about Initials only containing CRYPTO and PADDING, I missed that.
The text already says the following now: Not sure when exactly this got added but I assume this is sufficient to address this issue? NAME NAME ?
I don't think the new text fully addresses this issue. In the new text, this statement is incorrect: What about PING frames for example? Additionally, the client's first flight won't contain extension frames because the client has no way of knowing whether the server supports them so this statement is somewhat misleading: What are middleboxes supposed to do if they see an unknown frame type, we should provide guidance there. I think we should just tell middlebox implementors to refer to that section of RFC 9000 and expect to parse all frame types, and fail parsing if they see a frame type they don't recognize. And while we're at it, we should also mention that CRYPTO frames might be out of order.
I would expect ping frame in the initial... so that sentence might still be fine. I think there could actually be extension frame in the first flight, e.g. if information was cached about the support of the extension. In any case, can you maybe propose text NAME ?
Extension caching doesn't work for initials because the server can still reject 0-RTT at this point. How about this text: