Code change:
update" problem: one client accidentally overwriting the work of another client that has been acting in parallel. <del> Conditional request preconditions are based on the state of the </del> <ins> 13.1. Preconditions are usually defined with respect to a state of the </ins> target resource as a whole (its current value set) or the state as observed in a previously obtained representation (one value in that <del> set).  A resource might have multiple current representations, each with its own observable state.  The conditional request mechanisms assume that the mapping of requests to a </del> <ins> set).  If a resource has multiple current representations, each with its own observable state, a precondition will assume that the mapping of each request to a (representations) is consistent over time.  Regardless, if the mapping is inconsistent or the server is unable to select an appropriate representation, then no harm will result when the precondition evaluates to false. Each precondition defined below consists of a comparison between a set of validators obtained from prior representations of the target resource to the current state of validators for the selected representation (response.validator).  Hence, these preconditions evaluate whether the state of the target resource has changed since a given state known by the client.  The effect of such an evaluation depends on the method semantics and choice of conditional, as defined in evaluation. Other preconditions, defined by other specifications as extension fields, might place conditions on all recipients, on the state of the target resource in general, or on a group of resources.  For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field (RFC4918). </ins> <del> (representations) will be consistent over time if the server intends to take advantage of conditionals.  Regardless, if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result when the precondition evaluates to false. </del> <ins> Extensibility of preconditions is only possible when the precondition can be safely ignored if unknown (like </ins> <del> 13.1. The request header fields below allow a client to place a precondition on the state of the target resource, so that the action corresponding to the method semantics will not be applied if the precondition evaluates to false.  Each precondition defined by this specification consists of a comparison between a set of validators obtained from prior representations of the target resource to the current state of validators for the selected representation (response.validator).  Hence, these preconditions evaluate whether the state of the target resource has changed since a given state known by the client.  The effect of such an evaluation depends on the method semantics and choice of conditional, as defined in evaluation. </del> <ins> ), when deployment can be assumed for a given use case, or when implementation is signaled by some other property of the target resource.  This encourages a focus on mutually agreed deployment of common standards. </ins> 13.1.1.

Related discussion:
text: without changing section numbering
implies that a precondition failure is a good safe mode. However, a precondition that isn't recognized by a server will not share this property. A server that does not recognize a header as a precondition will ignore it and likely proceed with handling the request even if the precondition expressed should have failed. Indeed, the same is true if a server ignores preconditions, though the specification effectively . is the only text I could find on defining new preconditions. (One thing I really want to avoid is server's applying special heuristics to headers that start with , because that is one of many poor outcomes if this is left.)
There is also the example in the section above that I suppose we could make a new section on precondition extensions, but they aren't a separate category (like If*). For example, my precondition proposal for 1.1 was an all-inclusive Unless that enclosed a logic bag (structured field value). Note that they have always depended on compliance-when-implemented, since I added the first (If-Modified-Since) in early 1994.
Does this need to be in this specification?
I think we're almost in the extension territory (I like the idea of a header field that lists the applicable precondition fields). As far as this specification goes, simply noting that new preconditions won't share properties of the core preconditions, in particular the expectation that it is understood by servers.
One grammatical nit.