I have a feeling this might be because tckedit is multi-threaded, so won’t guarantee ordering is preserved. Can you run all this again with the -nthread 0 option to tckedit to disable multi-threading, see if that resolves the issue?
Assuming that was the problem, this might be something that we’d need to do something about. At the very least, document the fact that ordering is only guaranteed with multi-threading disabled. The reason we typically don’t worry about ordering is that in most cases, tracking is random, so there is no particular order anyway. But this issue might also suggest that invoking two separate calls to tckedit like this might not split the file perfectly, in that the streamlines near the split may end up in either batch, depending on which thread happens to get there first. I’m not sure whether this does happen, but it’s certainly something to verify. This would also be relevant for this recent discussion.