Representing state changes as multiple distinct asynchronous events can be awkward

I know this is a thing that is done all over the DOM APIs, but consider the use case that this interface is designed for: an editor that manages its own visual representation of the document (in the browser DOM). When a textupdate event comes in, it updates its document to reflect the change. It then forces a DOM layout because it needs to give the edit context the appropriate control and selection bounds. For compositions, this event is then immediately followed by a textformatupdate event, which requires another DOM update. Without dodgy tricks like delaying the response to events when we expect other events to happen (which introduces new asynchronicity and potential problems around state mismatches between the edit context and the rest of the system), this is going to waste CPU time by running multiple updates for a single editing event.

At least, I assume (hope) that the information about edits and styling coming from the IME systems comes as a single package, not a stream of asynchronous events as well.

I'm not quite sure what a good solution would look like. Systems that have a single event type for all state changes, with information about what actually happened in the event object, avoid this, but that might conflict too much with the design style of the rest of the DOM. Allowing the textupdate handler (or any code, really) to 'flush' format changes, somewhat like MutationObserver.takeRecords would help.

Start by reviewing the EditContext event flow described in the issue, especially the sequence from textupdate to textformatupdate during compositions. Compare the proposed single-event approach with a flush mechanism like MutationObserver.takeRecords; done means the API design resolves whether related state changes can be handled without redundant DOM updates.