Code change:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Related discussion:
text: 5.5. <del> The "Warning" header field is used to carry additional information </del> <ins> The "Warning" header field was used to carry additional information </ins> about the status or transformation of a message that might not be <del> reflected in the status code.  This information is typically used to warn about possible incorrectness introduced by caching operations or transformations applied to the payload of the message. Warnings can be used for other purposes, both cache-related and otherwise.  The use of a warning, rather than an error status code, distinguishes these responses from true failures. Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only be applied to response messages. Multiple warnings can be generated in a response (either by the origin server or by a cache), including multiple warnings with the same warn-code number that only differ in warn-text. A user agent that receives one or more Warning header fields SHOULD inform the user of as many of them as possible, in the order that they appear in the response.  Senders that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind.  A sender that generates new Warning header fields MUST append them after any existing Warning header fields. Warnings are assigned three digit warn-codes.  The first digit indicates whether the Warning is required to be deleted from a stored response after validation: 1xx warn-codes describe the freshness or validation status of the response, and so they MUST be deleted by a cache after validation. They can only be generated by a cache when validating a cached entry, and MUST NOT be generated in any other situation. 2xx warn-codes describe some aspect of the representation that is not rectified by a validation (for example, a lossy compression of the representation) and they MUST NOT be deleted by a cache after validation, unless a full response is sent, in which case they MUST be. If a sender generates one or more 1xx warn-codes in a message to be sent to a recipient known to implement only HTTP/1.0, the sender MUST include in each corresponding warning-value a warn-date that matches the header field in the message.  For example: Warnings have accompanying warn-text that describes the error, e.g., for logging.  It is advisory only, and its content does not affect interpretation of the warn-code. </del> <ins> reflected in the status code.  This specification obsoletes it, as it is not widely generated or surfaced to users.  The information it carried can be gleaned from examining other header fields, such as </ins> <del> If a recipient that uses, evaluates, or displays Warning header fields receives a warn-date that is different from the value in the same message, the recipient MUST exclude the warning- value containing that warn-date before storing, forwarding, or using the message.  This allows recipients to exclude warning-values that were improperly retained after a cache validation.  If all of the warning-values are excluded, the recipient MUST exclude the Warning header field as well. The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description of its meaning. The procedure for defining additional warn codes is described in warn.code.registry. 5.5.1. A cache SHOULD generate this whenever the sent response is stale. 5.5.2. A cache SHOULD generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach the server. 5.5.3. A cache SHOULD generate this if it is intentionally disconnected from the rest of the network for a period of time. 5.5.4. A cache SHOULD generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours. 5.5.5. The warning text can include arbitrary information to be presented to a human user or logged.  A system receiving this warning MUST NOT take any automated action, besides presenting the warning to the user. 5.5.6. This Warning code MUST be added by a proxy if it applies any transformation to the representation, such as changing the content- coding, media-type, or modifying the representation data, unless this Warning code already appears in the response. 5.5.7. The warning text can include arbitrary information to be presented to a human user or logged.  A system receiving this warning MUST NOT take any automated action. 5.5.8. The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines the namespace for warn codes.  It has been created and is now maintained at <https://www.iana.org/assignments/http-warn-codes>. A registration MUST include the following fields: Warn Code (3 digits) Short Description Pointer to specification text Values to be added to this namespace require IETF Review (see RFC8126). </del> <ins> . </ins> 6.