The major part that altered this behavior comes from the introduction of the following if-block inside #cascadeLogicalOneToOneOrphanRemoval.

if ( valueEntry == null && loadedValue instanceof HibernateProxy ) {
	// un-proxy and re-associate for cascade operation
	// useful for @OneToOne defined as FetchType.LAZY
	loadedValue = eventSource.getPersistenceContext().unproxyAndReassociate( loadedValue );
	valueEntry = eventSource.getPersistenceContext().getEntry( loadedValue );
}

What this block did not account for was that after the #unproxyAndReassociate invocation that there could be a possibility that child and loadedValue may point to the same instance, in which case we should not trigger the orphan removal; hence the additional if-check I mentioned in a prior comment to satisfy this use case.

Beyond that, I cannot think of any other use case where this creates an issue. In fact, removing the above referenced if-block where we reassociate allows the user's test case to pass; however that does revert and break the fix we were accomplishing for HHH-9663 Closed . So I think the extra if-check to compare the reassociated loadedValue with child to abort the cascade delete-orphan is the best of both worlds and shouldn't create any other issue.