Currently platform text input plugins and the framework have their own local replicas of the document being edited by the user. A local update to one document will be sent to update the other (remote) document to keep both in sync, using a platform channel message. It is crucial that both replicas having the exact same state when all communications are finished, to make sure the platform (and the system services like IME, autofill, etc,.) and the framework are looking at the same document.

Our current strategy is to encode the entire document in each update message to the remote document and overwrite the remote document. To avoid sending the same document over and over (echoing), both the platform text input plugin and the framework have logic to track the last known state of the remote document and only send updates when the local document's state is different from the last known remote state. There's a (not so slim) chance the states of the 2 replicas diverge after concurrent edits on both documents:

The text input plugin and the framework's documents are initially synced, both start from S(0, 0). If a local edit brings the text input plugin's state to S(1, 0) and before the change can be synced to the remote document, the remote document also makes a change that brings its state to S(0, 1), with the current implementation the 2 documents simply exchange states thinking the other document is in the same state.

With the current implementation the consistency is likely to be quickly restored, when the next update arrives (thanks to the redundancy in each update message) , however this may still cause unexpected behaviors, for instance the IME's predictive text bar may show completely irrelevant suggestions when this happens.

As #87972 is being implemented it's likely that in the future we'd like to remove the redundancy in each diff-based update message to free up the bandwidth/memory, which will absolutely require both documents to converge (otherwise they're going to diverge further and further).