Correct. So the example "works", it just makes a poor assumption leading to surprising results. But the thing is, it kind of has to make that decision based on how the SPI is designed. It all comes back to what I mentioned a few comments ago wrt what I believe in retrospect to be some poor design choices:

... initially I decided to split Region into specific contracts based on the type of data to be stored there (entity, collection, etc) so that the cache provider could apply any specific configuration it wanted based on that. However, as we have seen people map different type to individual regions - like my example above mapping entity and collection data to the region "a.b.c".
This means we have a mismatch of sorts. From one perspective a Region is identified by regionName, but from another it is identified by (category,regionName). So clearly that is poorly designed at the moment...

In the changes I "proposed" CacheImpl would simply cache Regions based on name (or that gets pushed to the provider as discussed in gist comments). So there is just Region (not EntityRegion, ...) we get a Region simply by name. From there we could ask that Region for different kinds of access strategies. Plus it allows Hibernate to then reliably access that information based solely on region-name too (for Stats, etc).

Those SPI changes would just make the design more clear. We can achieve that today without those SPI changes, CacheImpl would just need to maintain a complex Map rather than a simple Map (regionName->Region).