[TheFlyingFish]

My feeling is that the most important situation to consider here is where the updating happens from third-party JS. If you're writing your own JS, it isn't that much harder to just target the selectedoption as well as the original one, and if you're using a full-fat framework like React or whatever it's downright easy. So I think the benefit of providing an explicit API to trigger a clone is limited.

So that leaves the various automatic options, either synchronous, debounced, or the fancy targeted version. This seems like a pretty straightforward complexity/performance tradeoff to me, with the synchronous version being the simplest (both to implement and to understand) and going up from there.

With that in mind, I'm inclined toward the middle option (changes are synced automatically, but batched in the next microtask) since it feels like the best balance of complexity/usability. Seems like it would eliminate some of the biggest performance footguns, without being too much of a bear to implement or too difficult to understand.

On the other hand, I would personally also be ok with no syncing at all, just the initial clone when an option is selected, if it would mean we get this feature sooner. Really looking forward to not having to roll my own dropdowns.

[jaffathecake]

> With that in mind, I'm inclined toward the middle option (changes are synced automatically, but batched in the next microtask)

fwiw, this is relatively easy to do yourself. Set up a mutation observer, and clone when the callback fires on a mutation within the selected option.