Collection.fetch retains stale models after server-side deletions without reset option

Symptom

A Backbone.Collection backed by a REST endpoint continues to hold models that no longer exist on the server after a fetch() call. The default merge semantics reconcile incoming records by ID but never remove local models that are absent from the response.

Context

The application relies on Collection.fetch() to refresh data after server-side schema migrations or bulk deletions. Because Backbone models are schemaless, there is no built-in mechanism to detect or roll back attribute-level changes. The only way to force a full replacement is passing {reset: true}, which changes the event contract from individual add/remove events to a single reset event.

Constraints

• Existing view listeners may be bound to add, remove, or change events and not to reset.
• Switching to reset: true can break UI updates that depend on granular events.
• Backbone, Underscore, and jQuery versions in the lockfile may exhibit subtle timing differences in sync completion.

Questions

1. What decision criteria should guide the choice between default merge and reset: true for a given synchronization scenario?
2. How can a codebase reliably support both event styles without duplicating listener logic?
3. Are there version-specific behaviors in Backbone.sync that affect the reliability of either approach?