Limits of jQuery .data() cache reconciliation with data-* attributes

When a UI re-render or rollback replaces markup that was previously augmented with jQuery, the element state can split between the DOM and jQuery's internal store. The goal is to decide which source should be authoritative for a given key after such a replacement, without silently mixing the two.

The documented behavior creates a hard limit: the first .data('key') read pulls the matching data-* attribute into jQuery's per-element cache, and later .attr('data-key', ...) edits are not reread for that key. Conversely, .data('key', value) updates only the cache and does not write the attribute. Replacement methods such as .html() and .replaceWith() run cleanData on removed nodes, so cached data and handlers on discarded nodes are lost unless nodes are detached or handlers are rebound.

Because jQuery provides no automatic two-way synchronization or rollback reconciliation, assuming the cache and attributes still match can leave stale UI state.

Which source should be treated as authoritative after a rollback: the current data-* attributes, the surviving jQuery cache, or an explicit re-initialization? How should code detect that a key was already cached before the replacement? Is there a supported pattern for preserving or discarding jQuery data across .html() and .replaceWith() without re-binding handlers?