It was not the intention to disallow sharing a single cache region for multiple types; so yes this looks like a bug in the details of how we ended up implementing it.

There was a performance problem in those situations in which one had a rather low cache hit probability, for which the "attempt load from 2nd level cache" operation was being a higher cost than the small occasional benefits it provided, mostly because of the allocation of heavy wrapper objects to translate from Hibernate internal keys to 2nd level cache keys. For those cases in which there was no need to wrap the id it will now use the native id directly, this makes enabling 2nd level cache a benefit for a wider scope of scenarios.
Clearly having multiple types share the same region should not qualify as a safe case and it should use either the original key factory, or pick a new one which would only contain the essential details like type & id in this case.
Note that entities of the same parent/child group (i.e. an entity and an extension of it) will be safe to share the same cache as they are guaranteed to use unambiguous ids.

So the current issue description "Cache keys no longer include the entity type" is not a bug but rather an enhancement. Clearly not being able to use the same region for multiple types, that definitely is a bug and a regression. Should we adjust this issue's title?

Do you have an example for which it's using the wrong key factory?