Woke up with some good ideas about how to allow the user to vet the correspondences that have been found. At the end of the comparison and adjustment process, the matches are now sorted by similarity with the most similar first. Then the app pops up a new window with a list of the lines to be matched in two listboxes, and displays each match as highlights in the two list boxes, allowing the user to specify whether a match is a direct correspondence, and interesting parallel, or is completely unconnected. They can work through the entire set like that, or when they've done all the significant matches, they can stop. I've also added a feature so that you can double-click lines to select a match which is somewhere else in the list directly, and then specify that as a good match. Once a correspondence is made, its lines get a grey background, so you can see the remaining unmatched lines easily.

Next I think I need to do this:

• Allow the user to choose to discard all non-significant matches before saving (that would be all matches which are below a certain level, or more likely, those which are etNone in their equivalence field (meaning the user has not specified them as matches or interesting correspondences).
• Create a file format in which all this data can be saved and reloaded as a block. The obvious thing is a zip file containing all the input and output files. This would enable you to stop work on a set of correspondences, then start again later.
• Write save/load code for the file format.
• Add one additional file type to the output format: a collocation of the two documents as a <teiCorpus>, incorporating with all the match data.
• Write XSLT for the document above so that it can be displayed as a "critical edition" based off either of the two texts.
• Figure out if it's worth writing code to incorporate more than two texts, or whether the user should do that manually.