What happens if there is a commit between the last merge and the reintegration merge in SVN?

Normally, when reintegrating an SVN branch into trunk, we create a history like this:

trunk   A---B---D---F---H
             \       \ /
branch        C---E---G---X

where G is a merge, H is the reintegration merge, and X delete the feature branch. I also get that there is a difference in the merge algorithm that SVN uses for G and H. So far, so good.

However, one thing is bugging me: This answer cites SVN documentation on what happens with a reintegration merge as: "And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!"

Since trunc + changes from branch = trunc + (branch - trunk) = branch, I conclude that the recorded state after a reintegration merge is always exactly the same as the recorded state at the end of the branch.

Now consider this history:

trunk   A---B---D---F---H---I
             \        \   /
branch        C---E-----G-----X

With the reasoning above, I'd assume that the changes from commit H are simply lost if I is a reintegration merge. Is this correct, or is there something I've missed?

Subversion know that last sync revision is F, so it calculate difference between trunk@F and branch@G and then apply it to working copy.

If destination working copy checked out revision F, then reintegrate will go smooth(without conflicts) and after that you update wc to H (possible conflicts) and be able to commit.

If destination working copy checked out revision H, then reintegrate merge will be performed on top of H (in this case possible conflicts during merge)

In any case nothing will be lost.