Unexpected conflict with ort merge strategy?

Hi folks,

I just came across a situation where the ort merge strategy chooses a
"worse" rename mapping than the recursive strategy - worse in the
sense of having a lower similarity score, worse in the sense of having
been a change in another commit (but I guess this is just a limitation
of git merge? It doesn't look for renames "iteratively" through
history when merging?), and finally worse in the sense of causing a
merge conflict that, given the previous two points, is unnecessary and
does not occur with recursive.

I've prepared a reproduction script, attached. It's probably a little
convoluted because I didn't know exactly what to look out for. This is
an extreme simplification of a real-life incident:

One file (folder1/firstfile.txt) is deleted independently in two
branches, and another somewhat-similar file (folder2/secondfile.txt)
is renamed (to folder2/secondfile_renamed.txt) and slightly modified
in one of them (in another commit).

When the branch with the rename gets merged in to the branch that just
had the delete, "ort" sees the rename as having been of
"folder1/firstfile.txt" to "folder2/secondfile_renamed.txt", despite
this being of a lower similarity than the real rename that happened,
and a conflict ensues.

Is ort supposed to choose the "best" rename choice, for a given set of
trees, and failing to do so here? Or is this a case of recursive
*accidentally* doing a better thing?

Thanks,
Tao