I've been wondering about something like that also. Right now, I feel like doing it with "graced" items might create a high amount of complexity, requiring new methods to fetch items from graced pools, being able to deal with a mix of hard and soft deleted items (should we create a set of interfaces/methods to allow controlling hard/soft delete, etc.)?

I've recently proposed two PRs that are related:

• [Cache] Add stampede protection via probabilistic early expiration #27009 to add probabilistic early expiration. This works for expired items, but not for invalidated tags.
• [Cache] Prevent stampede at warmup using apcu_entry() for locking  #27028 to add per fpm pool locking, so that synchronous recomputation happens only once per front server.

I'm wondering if these proposed approches couldn't be enough in practice to make it unecessary to implement anything like graced items. That'd be great because that'd mean less complexity.
WDYT?

I think I found a way:

1. Initially set cache expiration to 0 (as I do not know when a write operation will occur which could alter the result)
2. When a write operation occurs, fetch all cache items by tag which could have been altered. Set their expiration date to past.
3. In a separate process fetch all cache items and check whether they have been expired or not and re-execute database query to re-warm the cache.

Would this be possible? Especially I wonder if 2. is possible (get cache items by tag).

"2." is not possible, and I think it goes off topic actually. Being able to do that requires a relational system, which does not exist and poses scalability issues. Solvable for sure, but not in a generic way IMHO.
Btw, if you happen to be able to know which items relate to tag "foo", another way to do it is by making tag invalidation do nothing BUT send a message to another process that could then recompute items in the background. This way, no need for graced items at all, and things might be optimal as everything happens in the background.

another way to do it is by making tag invalidation do nothing BUT send a message to another process

You mean by implementing an own class which implements TagAwareAdapterInterface?

implementing an own class which implements TagAwareAdapterInterface

correct!

I underestimated your "if you happen to be able to know which items relate to a tag"

Is it possible to let AdapterInterface::getItems() return all items, regardless whether they are valid or not? Invalidated items could get isHit = false. We could introduce a second parameter $invalid = false to AdapterInterface::getItems() so there would not be a backwards incomptible change.

I think it's not: design wise having a well though but restricted domain is desired. E.g. fetching all items from the backend doesn't scale with millions of items...

I meant not all items in general but all items which have the given key or tags, e.g. AdapterInterface::getItems(['foo']) could return CacheItems with isHit=true (valid items) and with isHit=false (invalid items).

items which have the given key or tags

that still exposes to the scalability issue and requires storing the relation in the backend.
Varnish (which is a great example of a tagged backend) doesn't have such feature.
That's why I don't think this belongs to the caching layer (we want to have in Symfony).

Closing as "won't fix", as explained. Thanks for proposing.