Currently we skip the up-to-date checks for query cache entries when the query is a natural-id lookup. The reason being to avoid the database hit due to the (potential) invalidation caused by changes to the entity. However, that is not correct behavior if the mutable natural key itself changed. This skipping should be limited to the case of immutable natural ids.
We should also clearly define the role of a natural ID. For example, can an entity identified by a natural ID be deleted and re-created with the same natural ID (but a different PK) – in the same transaction? The same Session? Ever?
That last comment was of course referring to the role of an IMMUTABLE natural ID. I.e., how "mutable" is it with regard to deletion and re-creation.
trunk / 3.2