Original text:
header field value containing a member "*" always fails to match. <del> The stored response with matching selecting header fields is known as the . If multiple selected responses are available (potentially including responses without a Vary header field), the cache will need to choose one to use.  When a selecting header field has a known mechanism for doing so (e.g., qvalues on </del>  and similar request header fields), that mechanism MAY be used to <del> select a preferred response.  If such a mechanism is not available, </del>  or leads to equally preferred responses, the most recent response (as determined by the <del> header field) is used, as per constructing.responses.from.caches. </del>  Some resources mistakenly omit the Vary header field from their default response (i.e., the one sent when no more preferable response is available), with the effect of selecting it for requests to that resource even when more preferable responses are available.  When a <del> cache has multiple responses for a target URI and one or more omits the Vary header field, it SHOULD use the most recent (see age.calculations) valid Vary field value available to select an appropriate response for the request. </del>  <del> If no selected response is available, the cache cannot satisfy the presented request.  Typically, it is forwarded to the origin server in a (possibly conditional; see validation.model) request. </del>  4.2.

Reviewer comments:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Revised text:
header field value containing a member "*" always fails to match.  <ins> If multiple stored responses match the selecting header fields (potentially including responses without a Vary header field), the cache will need to choose one to use.  When a selecting header field has a known mechanism for ranking preference (e.g., qvalues on </ins> and similar request header fields), that mechanism MAY be used to  <ins> choose a preferred response.  If such a mechanism is not available, </ins> or leads to equally preferred responses, the most recent response (as determined by the  <ins> header field) is chosen, as per constructing.responses.from.caches. </ins> Some resources mistakenly omit the Vary header field from their default response (i.e., the one sent when no more preferable response is available), with the effect of selecting it for requests to that resource even when more preferable responses are available.  When a  <ins> cache has multiple stored responses for a target URI and one or more omits the Vary header field, the cache SHOULD choose the most recent see age.calculations) stored response with a valid Vary field value. </ins>  <ins> If no stored response matches, the cache cannot satisfy the presented request.  Typically, the request is forwarded to the origin server, potentially with preconditions added to describe what responses the cache has already stored (validation.model). </ins> 4.2.