Theoretically, Joe could write anywhere on a blank canvas or next, below, within, somewhere near other text in the future. Still, he decides to use tracking_text_editor_1 (code), which automatically tracks all his operations (unfortunately, the Java implementation doesn’t work properly: depending on commit, host operating system or Java Runtime Environment implementation and/or my code/approach, ~1:1500 characters is recorded incorrectly because of timing/event issues, which is very bad for an text editor. I’m thinking about reimplementing the tool in C++ and Qt or with the web stack). The base text of a document can be constructed from those operations (change instructions) by the help of the change_instructions_executor_1. This way, all of Joe’s writing is always versioned, and not via conventional heuristical diff (which is guessing more or less), but in a way that allows to replay every single text operation. The change_instructions_executor_1 applies all operations up to the last, most recent one, but there should be a tool that allows to step through each operation individually (backwards, forwards, jump). That allows Joe to branch off other versioned variants at any stage of the upstream version graph of the text. It’s not clear yet if merging will be possible later, at least there should be the chance to determine where a text position moved to or if it was deleted, so merge conflicts should be unambiguously identifiable and never again a wrong result of heuristic guessing. It could be that there’s no way to edit an existing text other than reconstructing a certain stage of the text starting from the very first edit operation in order to prevent that any history is ever lost, but people probably can trick the system by inserting one huge add operation that adds the entire text in one go without individual editing operations. Other than cheating, there could be legitimate reasons to loose some of the history: one tool could condense editing operations, so gross add and delete operations eliminate themselves into net operations, to get from the source text to the destination text with the minimal amount of operations absolutely required, still maintaining their chronological order. This can save storage if such operations are irrelevant anyway, and it could be that people want to publish an update for their text, where the update isn’t comprised of each individual edit operation, but just the actual diff expressed in “net operations”. If people don’t want to publish all of the history, a receiving system couldn’t tell anyway if such history is missing or if the author just did one perfect run of edit operations, but the update needs to consist of the minimal net operations at the very least, because those will be used to construct/compose the new updated base text as no final text without it’s history will ever be accepted. Publishing a new update is done by submitting/transfering the edit operations that will lead to the updated base text from the last version of the text that’s already present.