Code change:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

Related discussion:
text: 6.5.2. <ins> The "Trailer" header field (field.trailer) can be sent to indicate fields likely to be sent in the trailer section, which allows recipients to prepare for their receipt before processing the content.  For example, this could be useful if a field name indicates that a dynamic checksum should be calculated as the content is received and then immediately checked upon receipt of the trailer field value. </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 <del> 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-based field even if each member value is only processed once per field line received. </del> <ins> as a list of members.  Trailer fields that might be generated more than once during a message MUST be defined as a list-based field even if each member value is only processed once per field line received. </ins> <del> 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 content stream, or won't be recombined (or dropped) in transit.  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. </del> <ins> At the end of a message, a recipient MAY treat the set of received trailer fields as a data structure of key/value pairs, similar to (but separate from) the header fields.  Additional processing expectations, if any, can be defined within the field specification for a field intended for use in trailers. </ins> 7.