EDIT

Code comment from PostMergeEntityListener.java:

// #10101 the following code tried to handle orphanRemoval for key nodes that were
// really removed from the graph. Generally the removal worked but it was not possible at this
// place to guarantee that the node which was removed from the parent was not used elsewhere
// (has a new parent). For this one needs to retrieve the new state of the node (or of its new parent).
// But this is not difficult or impossible at this point as the node is not part of the graph to
// to be merged or if it is because its new parent is part of the graph also, it is not guaranteed
// that it has already treated so far.
// Maybe it can better be handled by another type of listener therefore I keep this code here.
// See #10101 for further information on this issue and how it was solved.
// The implementation was partly copied from https://stackoverflow.com/questions/812364/how-to-determine-collection-changes-in-a-hibernate-postupdateeventlistener

https://dev.e-taxonomy.eu/gitweb/cdmlib.git/blob/e1284d9aace334813f3bee700c1aa1127033f1ef:/cdmlib-persistence/src/main/java/eu/etaxonomy/cdm/persistence/hibernate/PostMergeEntityListener.java

I removed the HHH_9751_Util class as it is currently not used anymore, please recreate from cb923587ce746 and taxeditor commit 09abc6569 if it is used in future again.

Comment from onMerge in PostMergeEntityListener:

Added in context of working on #10101, it was unclear to me
why this method was not implemented before. Debugging the merge process
revealed that this method was primarily called on the first entity
to merge (as copied already is not necessary then).
So setting the ID and adding to the newEntitiesMap seems
not to be implemented for entities handle only here.
Needs intensive testing if there is not maybe a reason why the method
was not implemented.

Finding duplicates:

SELECT pkn.key_id, pkn.parent_id, pkn.sortindex, COUNT(*) AS n
FROM PolytomousKeyNode pkn
GROUP BY pkn.key_id, pkn.parent_id, pkn.sortindex
HAVING n > 1;

SELECT tn.classification_id, tn.parent_id, tn.sortindex, COUNT(*) AS n
FROM TaxonNode tn
GROUP BY tn.classification_id, tn.parent_id, tn.sortindex
HAVING n > 1;

SELECT tr.graph_id, tr.parent_id, tr.sortindex, COUNT(*) AS n
FROM TermRelation tr
GROUP BY tr.graph_id, tr.parent_id, tr.sortindex
HAVING n > 1;

A helpful SQL for checking the correctnes of the sortindex (here for PKNode):

SELECT pkn.id, pkn.created, pkn.updated, nodenumber, key_id, parent_id, sortindex 
FROM PolytomousKeyNode pkn
 WHERE key_id = 24
ORDER BY key_id, parent_id, id, sortindex;

SELECT pkn.id, pkn.created, pkn.updated, nodenumber, KEY_id, parent_id, sortindex, pkn.revtype
FROM PolytomousKeyNode_AUD pkn
 WHERE key_id = 24 OR id = 394
ORDER BY key_id, parent_id, id, sortindex