I don't think you discuss how conflicts are resolved beyond updating the view to Windows Text Services

[BoCupp-Microsoft]

Can you also say how the text actually gets committed to the DOM in the case of conflict, e.g. if selection moves in the DOM but TSF is requesting you replace "abc" (3 characters which formerly preceded the caret) with "xyz"?

[siliu1]

The behavior is consistant across all platforms in such scenario. Requests from TSF to commit text into DOM are always based on current selection. If a change in selection which breaks TSF's assumption of selected text, then the committed text will be inserted at new selection's location. In this scenaro, the previous selection is [0,3] and text in DOM is "abc", TSF wants to replace "abc" with "xyz". However, selection changed from [0,3] to [3,3]. "xyz" is inserted at [3,3] instead of replaceing "abc". The text in DOM becomes "abcxyz". TSFTextStore detects that the text is different from expected text "xyz", Windows Input Service will be notified about the text change.

[BoCupp-Microsoft]

Looking at SetCompositionText it looks like the protocol for composition is really coded to be stateless. It removes whatever is currently tracked in the renderer as composition text, then it removes any selection, then it inserts the new composition text at the caret. The requested location of the change is ignored... is that right?

Maybe a good scenario to consider where there's contradiction from JS would be suggestions? What happens when selection changes in JS but TSF asks to complete what you were typing?