Original text:
connection error of type H3_FRAME_UNEXPECTED (errors).  In particular, a DATA frame before any HEADERS frame, or a HEADERS or DATA frame after the trailing HEADERS frame is considered invalid.  A server MAY send one or more PUSH_PROMISE frames (frame-push- promise) before, after, or interleaved with the frames of a response Frame types of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored (extensions).  These frames have no semantics, and <del> can be sent on any open stream when application-layer padding is desired.  They MAY also be sent on open streams in connections where no data is currently being transferred.  Endpoints MUST NOT consider these frames to have any meaning upon receipt. </del>  The payload and length of the frames are selected in any manner the implementation chooses.

Reviewer comments:
NAME does this address your concerns?
Section 7.2.8: URL These frames have no semantics, and can be sent on any open stream when application-layer padding is desired. So I am uncertain if it is acceptable to shoehorn in a reserved frame after a frame that is supposed to be the last and then result in a close of the frame? Based on what is written I would lean to the interpretation that it is allowed, as the frame sender has decided to not close the stream yet, and thus it is open. If this is correct interpretation than it is up to the editor if they like to clarify more. Else something needs to be done.
The best example here is sending a reserved frame after a Request stream is opened by the client. Perhaps it is useful to call that out in section 4.1. is a bit loose. You can't send frames on qpack streams for instance, or as the first bytes on a push stream. Maybe we can rephrase it as, "Can be sent on any stream where frames are permitted to be sent"
There are no frames that close the stream, because stream closure is handled by the transport. SETTINGS is special in that it is required to be first, and is covered by : It would hypothetically apply to a future frame type which is required to come at the end of the stream as well, but we have no such frames at this time. ( does impose specific ordering on DATA and HEADERS frames relative to each other, but says nothing about other frame types.) NAME point is well-taken, and I'll take that text.
NAME does the PR address your issue?
Yes, I think this PR clarifies things a bit and are sufficient to resolve my issue.
Labeling this as "editorial" based on

Revised text:
connection error of type H3_FRAME_UNEXPECTED (errors).  In particular, a DATA frame before any HEADERS frame, or a HEADERS or DATA frame after the trailing HEADERS frame is considered invalid. <ins> Other frame types, especially unknown frame types, might be permitted subject to their own rules; see extensions. </ins> A server MAY send one or more PUSH_PROMISE frames (frame-push- promise) before, after, or interleaved with the frames of a response Frame types of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored (extensions).  These frames have no semantics, and  <ins> MAY be sent on any stream where frames are allowed to be sent.  This enables their use for application-layer padding.  Endpoints MUST NOT consider these frames to have any meaning upon receipt. </ins> The payload and length of the frames are selected in any manner the implementation chooses.