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

Core Issue

Backbone.Collection.fetch() uses merge semantics that reconcile incoming records by ID but never remove local models absent from the server response. This means server-side deletions appear as stale data on the client.

Decision Criteria

Use {reset: true} when data consistency with the server is the priority—specifically when:

• Server-side deletions or bulk operations are expected
• The collection represents a complete, bounded dataset (e.g., a list view)
• Local state mutations are not critical to preserve

Stick with default merge when:

• Preserving unsaved local changes matters
• Users expect models to persist across fetches
• The collection is a partial view subject to filtering

Supporting Both Event Styles

Without duplicating listener logic, abstract event handling through a mediator or wrapper:

1. Create a syncCollection mixin that normalizes events
2. On reset, compute the diff between old and new sets and fire synthetic remove events for deleted models
3. Fire synthetic add events for new models, maintaining the same contract as granular updates

Version Behavior

Backbone.sync handles reset consistently in 1.3.x and 1.4.x. The primary variation across versions involves jQuery's AJAX completion timing, which may affect when events fire but not the final state. Underscore-Blinder version mismatches can cause iteration errors in manual implementations, so verify versions in your lockfile.

Verification Steps

1. Delete records on the server, then call fetch() without reset—confirm stale models persist
2. Repeat with fetch({reset: true})—verify collection length matches server state
3. Audit all listenTo bindings for add, remove, change—identify components that would miss reset events