Change:
9. <del> The encrypted payload of an OHTTP request and response is a binary HTTP message BINARY.  Client and target agree on this encrypted payload type by specifying the media type "message/bhttp" in the HPKE info string and HPKE export context string for request and response encryption, respectively. Future specifications may repurpose the encapsulation mechanism described in hpke-encapsulation, provided that the content type of the encrypted payload is appropriately reflected in the HPKE info and context strings.  For example, if a future specification were to use the encryption mechanism in this specification for DNS messages, identified by the "application/dns-message" media type, then the HPKE info string SHOULD be "application/dns-message request" for request encryption, and the HPKE export context string should be "application/dns-message response" for response encryption. 10. </del> Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] for the media types "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). <del> 10.1. </del> <ins> 9.1. </ins> The "application/ohttp-keys" media type identifies a key configuration used by Oblivious HTTP. <del> 10.2. </del> <ins> 9.2. </ins> The "message/ohttp-req" identifies an encrypted binary HTTP request. This is a binary format that is defined in request. <del> 10.3. </del> <ins> 9.3. </ins> The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response. <del> 10.4. </del> <ins> 9.4. </ins> IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. <del> 11.  References </del> <ins> 10.  References </ins> <del> 11.1.  URIs </del> <ins> 10.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types

Discussion:
This is a lot more disruptive, but I think it is a clearer description of how you might repurpose this design. I'm still a little unsure about using application/dns-message, but I can live with it.
If this is acceptable, I might cherry-pick some of the other changes from rather than take it wholesale.
OK, I think that I understand what you are looking for and I agree, we can say more about that. But we probably don't need to say heaps more. Is the latest commit what you are looking for?
NAME I think it's closer, but I genuinely don't see why noting precisely where things need to change in the spec is harmful. I prefer Tommy's original change here.
Yeah, this still doesn't solve the problem of letting implementers know which parts of the encapsulated request processing are the bits that can become generic to handle other media types. Another way to look at this is, for another spec to define how to use another media type, it should be easy to simply say "the OHTTP spec explains the couple places where the media type can be changed from BHTTP to something else — and this use of OHTTP tells you to use a different media type in those spots". We should avoid having new specs like this need to wholesale copy the sections of the OHTTP document that define how to use HPKE, etc, and just have one subtle difference.
I'm not seeing that. I realize that I missed the padding piece (though I don't consider that particularly important, it's worth mentioning). For a generic format, the only adaptation required is replacing the constant strings. This describes how that might work. That we don't burden the reader of the algorithm piece with this detail at the time is a feature, not a bug, as far as I'm concerned.
I don't consider it a burden. I think it's an important piece for someone who's implementing OHTTP since it has API implications. For example, one could implement the main encap and decap algorithms using the fixed "message/bhttp" content type and then find they have to either duplicate code later on adjust their encap and decap APIs (or something else) to accommodate another type of application encoding.

The inline hints from the original suggestion in suggest that implementers might want to allow for changes to the content type string so they don't run into this situation down the road, and they're minimally invasive hints at that.
I've added the pointers, as requested. (I only skipped one on the decapsulation process as that seemed redundant.)
Thanks, latest changes look good to me