Can we bring this to CachingHttpClient (with a BC layer) instead of introducing a new class that is the good implementation of caching but with a name that is much less clear ?
Also, having the RFC id in the class name is a bad idea to me, as it would be a pain if a new RFC gets released to replace the current one (which happened multiple times for RFCs related to HTTP)

UPDATE:

• CI failure on PHP 8.5 is unrelated
• Psalm failure seems to be a false positive to me
• Tests pass locally on low deps, but not on github actions. I need to look at it.
• I don't know how to please fabbot. Should I not make any change to the upgrade file ?

Otherwise, PR is ready on my side. Ready for another reviews.

Not sure about locking as a first step, maybe just some pointer would be enough: while writing, we use some random key name, and once the cache is populated, we update some other pointer key, this one predictably derived from the request. When the cache is stale or empty, that'd mean writing many concurrent streams to the cache backend for the same request, until one finished and wins of the others. No ideal, but at least correct from a behavioral perspective.
The next step would be to wrap everything in one may $cache->get() callback, which would the act as the lock unit, possibly capable of serving something while revalidating and/or waiting/streaming while the concurrent write thread is doing its job. I'd be fine doing this next step in a follow up PR if that's too involving for this one.