Mithril auto-redraw and manual m.redraw() boundaries in async state updates

Mithril.js keeps views synchronized with state through an automatic redraw system that activates after DOM events and AJAX requests. When state changes occur outside those boundaries—inside setTimeout callbacks, WebSocket message handlers, or other external event listeners—developers commonly call m.redraw() to trigger reconciliation. The exact boundary where these two mechanisms overlap remains a practical concern.

Because Mithril rerenders the component tree by comparing new virtual DOM output against the previous tree rather than tracking discrete property mutations, every redraw carries a cost proportional to tree size. A known behavioral characteristic is that invoking m.redraw() immediately before an automatic redraw can cause double-renders, but the precise scheduling conditions that produce this behavior are not always obvious in complex asynchronous chains.

For teams integrating Mithril with external event sources, the unresolved question is how to coordinate manual redraws with the framework's internal lifecycle without introducing redundant renders or stale views. Version differences in redraw scheduling may further affect the correct integration approach.

1. Under what specific timing conditions does a manual m.redraw() call coalesce with, rather than duplicate, an automatic redraw already scheduled by Mithril's event system?
2. How does the virtual DOM diffing algorithm process intermediate trees when both manual and automatic redraws execute within the same JavaScript task?
3. Which integration boundaries—timers, external event listeners, or AJAX callbacks—require manual redraw coordination to avoid stale views without forcing extra reconciliation passes?