1) If you've had 10 unique cache gets, there are all misses and then fall back to the primary cache and this is reported as a warning which is a total red herring.
Instead it should only be concerned with the delta between the static cache and the real cache stores. In fact its almost the other way around, it should detect the number of unique cache keys used (maybe a new U columns for just the static caches), vs the current simple total, and then if the unique keys is lower than the total, and there isn't a static cache then its a potential candidate and should warn.
The only warning for when a static cache is used might be if its overused for something super heavy like say modinfo. But none of the cache stuff mentions memory at all, so maybe that's a new value at the top eg 'Static cache memory'.
2) Request caches are also shown a bit funny, they should have similar logic to the static caches
3) The eventinvalidation could be a separate tracker but its similar in that its a red herring we want to clean up. Its internal to the Cache API so I think could be given special treatment, perhaps moving it to its own line and / or suppressing the warnings on it.
On a warm page re-load of almost any page in moodle there should be very few or no warnings (and if there are legit ones then that should spawn new trackers)