For reference, the intent of this PR is to provide a basic block that could allow building something like Drupal Contexts:
https://www.drupal.org/developing/api/8/cache/contexts

@andrerom or anyone else, any comment here?

So this can for instance be used by HttpCache so it can handle very by logic right?

Yes for sure.https://www.drupal.org/developing/api/8/cache/contexts is a real use case of this feat. Maybe one should first read this page then help me find the right words to explain the feat. ? :)
This is hierarchical invalidation done from theoutside, (theinside being prefixing keys explicitly e.g.->getItem('foo/bar'))

well I looked at that page, and couldn't help but think most of these use cases(incl Http Cache) could be solved by reflecting context in key, as invalidation is done with tags it won't complicate invalidation, and lookup will need to know the context of what they are looking for anyway.

But I'm probably overlooking something.

could be solved by reflecting context in key

true, and this feat. is exactly here for decoupling this: context computation and keys.
You can create the context outside, then give a regular but contextualized adapter to another service that shouldn't care about the context it's working in.

Vocabulary changed: the interface is now calledContextAwareAdapterInterface and its methodwithContext().

Any comment here? Any vote @symfony/deciders?

So, thinking a bit more about this: should calling deleteItem on a parent also clear the item recursively? Looks like it could be useful. Then what about the other psr6 methods? Dunno. Which means this isn't ready :)
Closing

The reason why there was confusion is that you need a 2-step cache_get() process - or a cache collector like 'Vary' if you want to use that.

It gets very useful once you have a sub-item use contexts that are not known to the parent.

It basically solves the problem for complex sub-items, which the parent can't query for its contexts and which even might not know its contexts until computation time.