It's 2 different problems, minimalistic example referenced at the end.

Having entity with natural ID, which associates N entities. Those one has composite, natural ID. The issue was found via SpringData SimpleJpaRepository, which calls persist/merge based on what ID entity has and what state it is, which should explain why I'm kinda trying to use merge incorrectly. But that's not important, this should work. Whole scenario happens within 1 tx, where we perform:

1. create entity with naturalID and single associated entity
2. persist/merge
3. remove item from collection of associated entities (or call clear on managed collection).
4. add item into collection of associated entities
5. tx commit.

notes: no call to flush is used, all happens in single opened tx. All entities managed state is what I'd expect it to be: ie. not managed before persist/merge, managed after. Both cascade and orphanRemoval is specified, collection instances are not somehow replaced during this process, which could make hibernate unaware of changes on them. Well .... as far as I understand.

Problem 1: if I use `persist` in step 2, to bring entity into persistence context, root entity and non-removed associated entity will be in DB after commit. The problem with persist is, that first associated entity is first added, and then removed, creating unnecessary delete operation. But at least the result is OK.

Problem 2: if I use merge instead of persist to bring entity into persistence context, the deleted entity is persisted, and the whole flow behaves differently. If persist is used, the DefaultDeleteEventListener is hit when trying to remove the item from managed collection. If merge is used, it's not, and removed entity is stored into db.

another attempt to describe/discuss it: https://stackoverflow.com/questions/71271201/orphanremoval-does-not-work-for-entities-with-naturalid-persisted-via-springdata

minimal working sample: https://github.com/alfonz19/orphan-removal-test/tree/justMergeFlow