I tried a simple proof of concept today. My idea was that SplitTwoColConflictHelper can start falling back to their parent TextConflictHelper when it runs into the described complexity exception. To test this I hacked Diff to always throw the exception. To my surprise the parent can't handle this exception as well, and ends crashing the same way. In other words: There is not much benefit in handling this exception in our code, esp. not when the idea is to fall back to the old conflict resolution interface. That would fail for the same reason.

Furthermore I found that this exception is handled within the set of Diff classes, and can never been seen from the outside. That was only possible because of my hack. Only WordLevelDiff sets a "bailout complexity". It expects the failure and falls back to showing the whole paragraph as a change, instead of a word-level diff. Paragraph-level Diff doesn't have a bailout.

A comment mentions other exceptions, but I'm not sure what they are. I can't find a try-catch in the core code that deals with diffs. My argument would be: As long as core's conflict resolution interface doesn't handle an exception, why would our alternative conflict resolution interface need to be better than core's? Or to phrase the argument differently: If there is an exception that needs to be catched and properly handled, that would need to be done in both the old and the new interface. That would be more a core task, not an exclusive Two-Column-Edit-Conflict-Merge task. Let's open one when the need arises.