I realized that the annotation matching code was a bit too generous with its selection of nodes, due to the preceding:: and following:: axis. I've now reworked it into something much more efficient and cleaner. The problem is that there are a number of different ways in which an editor might select a bit to annotation; the best way would be to point directly to an element (say an l or an lg), but most often editors want to gloss particular words or phrases using an anchor, so we have to handle both (and both in combination: say something starts at a line but ends halfway through another). So the solution to this is to first generate all the nodes that are between the two boundary points (using the incredibly fast << and >> selectors, which I've just learnt about) and then group them based off of ancestor nodes that were in that original selection of nodes. (That's not a very elegant way to describe it, but it's all documented heavily in the XSLT.)

This new process shored up a number of issues with the annotations. Many of them are aesthetic, some are functional, and some are processual. We'll have to have a set of diagnostics to check whether or not something that was annotated with anchors could be better annotated by pointing to a line or a line group. That won't be trivial, so that'll take some time