Firstly, we could have better suffix generation. If we keep track of the shared child when we split threads due to going back through a merge, and keep track of the children when we merge threads due to going back through a fork, we might be able to stack suffixes - so if the trunk was merged from -1 and -2, but then -2 was merged from two others, we could call them -2-1 and -2-2.

When merging suffixes as we go back through a fork, however, we need to be more careful. If the suffixes going in have a shared prefix, perhaps we can just use that - but can we be sure there won't be duplicateion? -2-1 and -2-2 might merge together into -2, and then -2-3 merges with -2 to also leave -2, which is fine, but what about harder cases?

The other thing, which is perhaps a bit safer, is to emit "dummy" fold outputs for forks and merges, to make them explicit. Entries that don't correspond to history entries, but are, in essence, comment markers.

To do this, have fold-history keep track of thread splits and merges (taking account of the fact that an N-way merge needs to be a single N-way merge rather than a chain of 2-way merges, despite it being handled that way currently), and after calling kons to tell it about the chosen thread moving onwards, then call kons for each split and again for each merge, listing them.

The splits and merges will need to be handled via extra arguments to kons, or passing more than one kons - a history entry kons, a split kons, and a merge kons. The mtime of the snapshot that generated the splits and merges needs to be presented to split/merge kons notifications.

These can then be converted into dirents, by generating names from the mtime (so they still sort correctly) with suffixes to reflect what's happening. They can be inline nodes containing a description of the split/merge.