Code change:
5.6.3. <ins> Like header fields, trailer fields with the same name are processed in the order received; multiple trailer field lines with the same name have the equivalent semantics as appending the multiple values as a list of members, even when the field lines are received in separate trailer sections.  Trailer fields that might be generated more than once during a message MUST be defined as a list value even if each member value is only processed once per field line received. Trailer fields are expected (but not required) to be processed one trailer section at a time.  That is, for each trailer section received, a recipient that is looking for trailer fields will parse the received section into fields, invoke any associated processing for those fields at that point in the message processing, and then append those fields to the set of trailer fields received for the overall message. This behavior allows for iterative processing of trailer fields that contain incremental signatures or mid-stream status information, and fields that might refer to each other's values within the same section.  However, there is no guarantee that trailer sections won't shift in relation to the message body stream, or won't be recombined (or dropped) in transit, so trailer fields that refer to data outside the present trailer section need to use self-descriptive references (i.e., refer to the data by name, ordinal position, or an octet range) rather than assume it is the data most recently received. Likewise, at the end of a message, a recipient MAY treat the entire set of received trailer fields as one data structure to be considered as the message concludes.  Additional processing expectations, if any, can be defined within the field specification for a field intended for use in trailers. 5.6.4. </ins> The "Trailer" header field provides a list of field names that the sender anticipates sending as trailer fields within that message. This allows a recipient to prepare for receipt of the indicated

Related discussion:
text: long-lived "uploading/downloading" in-band signaling support such as load reporting, app-level flow-control, authn update etc Semantics trailers are a special case of mid-stream metadata, e.g. only trailers are able to convey the status of the entire transaction or the entire resource (body) our experience is that in-order delivery is useful and often assumed, since the underlying transport (for HTTP body) is in-order and reliable. Out-of-order metadata is likely a use case for connection-level metadata, IMO with the above assumption on in-order delivery, you really only need one API for delivering in-stream or trailer metadata Multi-part without in-stream metadata, you would have to use multipart (with all the overhead) for structured data, the original content-type can be preserved, e.g. JSON stream; and for media data, the content-type may have to be application/octet-stream
Copying over the questions from NAME over in URL, as they are good ones:
The semantic model of trailers is that they provide additional metadata that may (or may not) be useful to recipients but was not available prior to the initial body data sent. How the are useful and what they might contain would be defined by the field name. A recipient is free to drop the trailer metadata. A mid-stream trailer frame would have the same role in flow control as a HEADERS frame, which is none at the current time. The proposed frames would not have any specific position, but the values inside trailer fields might identify specific positions (on their own, regardless of framing). A cache would either drop the values or store them separately as trailer fields in the order received.
HTTP/2's flow control only cares about DATA frames. But all frames are subject to TCP's flow control. In HTTP/3, all frames are sent on streams which is subject to QUIC's flow control. Responding to the original question, I don't know what a "new form of flow control" would look like and I don't see how one would improve things.
What's the minimal change that would need to happen to semantics to enable this in a future version of HTTP (or an extension to an existing one)?
I think you would need to make "trailer part" less special, and simply say that a version of HTTP can define a way to carry additional field sections during or after the body.