Reverse Proxy cache feature scope?

Looking at https://github.com/microsoft/reverse-proxy/issues/120 I see there is a intention to cover reverse proxy cache use cases in the future.

Unsure what scope you aim for, and what you would deem to belong to backend application caching logic.

I'm also unsure what is already possible by means of YARP custom proxy coding.

So some of these feature suggestions might be irrelevant, so feel free to point to doc / shoot down any of this. Its first and formost meant to ask about scope for future Reverse Proxy cache support in YARP.

**Common "Http Cache" features**:
- Cache based on cache headers
- [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) _including support for useful extensions like stale-if-error and stale-while-revalidate_
- Suggestion: Prefer `YARP-Cache-Control`, then `Surrogate-control` before fallback to `Cache-Control`, then `Expires`
- Allows Cache-Control/Expires to be reserved for client and shared cache (ISP, Airplane, ...), and not having to transform cache headers for public internet use, further arguments: [akamai.com/blog](https://www.akamai.com/blog/news/targeted-cache-control). See [rfc9213 Targeted HTTP Cache Control](https://httpwg.org/specs/rfc9213.html) and [w3.org Surrogate-control](https://www.w3.org/TR/edge-arch/) / [draft-nottingham-surrogates-00](https://datatracker.ietf.org/doc/html/draft-nottingham-surrogates-00)
- _Regardless of status of cache in YARP, support for these headers in ASP.Net Response Cache would be great if not already possible_
- [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#vary)
- [Heuristic caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#heuristic_caching)
- ...
- Caching based on configuration - Typically forcing cache of certain responses / paths even if application did not intend it
- Also: Normalizing query string, dealing with cookies (tracking cookies++), for more topics see [VCL example](https://www.varnish-software.com/developers/tutorials/example-vcl-template/)
- Different cache backends: memory, disk, or hybrids _(smaller and frequently requested content in RAM for performance, larger/less-frequent content on NVMe/SSD/..)_
- ESI - Be able to split out responses in smaller chunks where needed (separating: public/semi-private/private parts, different sections with different TTL, ...)

**Integration features**:
- Cache tagging - In many dynamic/abstracted content/e-commerce applications entities can be present in a lot of responses and placed there by end users dynamically, by supporting cache tagging the application does not need to keep track of all resulting urls, instead it tags responses with id for the entity. See [Varnish xkey/ykey](https://docs.varnish-software.com/varnish-enterprise/vmods/ykey/), and somewhat more standard like header usage in Fastly: [Surrogate-Key](https://developer.fastly.com/reference/http/http-headers/Surrogate-Key/)
- Cache invalidation by backend (secured/authenticated): path, domain, headers, tags. See Symfony's [FOSHttpCache](https://foshttpcache.readthedocs.io/en/latest/cache-invalidator.html) for inspiration.
- Support vary by application secrets - Some responses or parts of responses vary on types of users, their profile settings, access rights (role or more complex), or other facets that we can't trust coming from the client side request. For this a (per user cached) lookup can be done to retrieve such secrets, that are then used to Vary responses on if present in Vary header, the application is responsible for invalidating this per user cache on relevant logout/changes. See [User Context Hash](https://foshttpcache.readthedocs.io/en/latest/user-context.html)

**CDN like features**:
- Asset transformation for formats or optimizing for client capabilities (movies, images, audio)
- Multi region/zone capability for the cache, either as clustered cache storage, or as separate caches and broadcast invalidations to all nodes