Plan cache entries (and here I am talking about both the classic and SBE plan caches) can be in one of four states with respect to how they interact with replanning:

1. Contains a "works" value. Such plan cache entries are written by the classic engine to the classic plan cache. The "works" value is used for triggering the classic engine's implementation of replanning.
2. Contains a "reads" value. This is used when the query executes in SBE (regardless of which plan cache is being used). The "reads" value is used for triggering SBE's implementation of replanning.
3. The plan cache entry is pinned, and has no reads or works value. As of this writing, this can only be the case for SBE plan cache entries, but SERVER-13341 could expand its use to the classic engine. This means that the plan can be retrieved from the cache, but the cached plan trial period will not run and replanning can never occur.
4. A cache entry which should only be used for a branch of an $or during subplanning for SBE. This is a special case introduced recently as part of SERVER-90415. Such cache entries are encoded with a special byte in their plan cache key to avoid conflation with other kinds of cache entries. I won't explain the need for this special case in full here, but it relates to the fact that the plan for the $or branch is recovered from the classic cache but the query as a whole executes in SBE. Since we currently do not support replanning for rooted $or queries (see SERVER-18777), such cache entries should not store either a "works" or a "reads" value.

Recent work completed in SERVER-90489 introduced the ReadsOrWorks sum type which is used to explicitly distinguish between case 1 and case 2 above. We should consider extending this sum type to have a third state which represents the "neither works nor reads" case. That could help code clarity and could also ensure that an assertion would trigger if we have a logic error that tries to obtain a works or reads value for a plan cache entry for either case 3 or 4 above.