In terms of design I think I did make one mistake in retrospect... 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. One option would be to do away the specific Region subtypes and collapse RegionFactory to just one method to obtain a named Region. Region would then have methods to get *AccessStrategy impls, like:

interface Region {
    ...

    EntityRegionAccessStrategy buildEntityRegionAccessStrategy(
            AccessType accessType, 
            CacheDataDescription metadata) throws CacheException;

    NaturalIdRegionAccessStrategy buildAccessStrategy(
            AccessType accessType, 
            CacheDataDescription metadata) throws CacheException;

    CollectionRegionAccessStrategy buildCollectionAccessStrategy(
            AccessType accessType, 
            CacheDataDescription metadata) throws CacheException;

    ...

}

The reason it would be nice to keep Region around is 2-fold that I see:

1. it makes a nice unified target for stats reporting
2. it makes SF level access (eviction, etc) simpler