Original text:
stored) from a prior request. An origin server that receives an If-Unmodified-Since header field <del> MUST evaluate the condition as per evaluation prior to performing the method. </del>  <del> If the selected representation has a last modification date, the origin server MUST NOT perform the requested method if that date is more recent than the date provided in the field value.  Instead, the origin server MAY indicate that the conditional request failed by responding with a </del>  status code.  Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected

Reviewer comments:
They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)

Revised text:
stored) from a prior request. An origin server that receives an If-Unmodified-Since header field  <ins> without an If-Match header field MUST evaluate the condition as per evaluation prior to performing the method. </ins>  <ins> To evaluate a received If-Unmodified-Since header field: An origin server MUST NOT perform the requested method if an If- Unmodified-Since condition evaluates to false.  Instead, the origin server MAY indicate that the conditional request failed by responding with a </ins> status code.  Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected