Thanks for the notes. The broken behaviour isn't your fault; I believe it was working reliably at one point but some refactoring of container management added an OBO error, I think. I should be fixing this myself, will investigate ASAP.
The algorithm isn't (or shouldn't be) quite as you describe it: we calculate the nearest reachable target position before the one the user requested. This doesn't always require undoing containers.
Remark: I believe that the tree (document model for script) ought to contain the parsed text including whitespace elements, ideally. Invariant: it should be correct at least as far as the processed point of the text (since the processed region is not normally edited). Therefore we can use it for undo calculations. Compared with the previous duplication of history mechanism, this loses if the user insists on editing processed text (we will require reparsing and then calculate undo according to new document contents). But current thinking is that if the user is editing the processed region they can expect to cause havoc anyway.
I've been tracking this under #24 (now changed priorities and moved milestone), so I'm marking this one as a duplicate.
