Change:
in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. <del> An encrypted HTTP response includes a binary-encoded HTTP message BINARY and no other content; see fig-res-pt. </del> <ins> This document defines how a binary-encoded HTTP request BINARY is encapsulated.  This Encapsulated Response format is identified by the iana-res.  Alternative encapsulations or message formats are indicated using the media type. The content of ""message/ohttp-res"" response encapsulation contains only a binary HTTP message; see fig-res-pt. </ins> Responses are bound to requests and so consist only of AEAD-protected content.  response describes the process for constructing and

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