TrackingCollection.CollectionChanged fired too early when removing items

Release Type: Official Release

Version: 4.3.0.2507 and prior

Platform(s): All

Describe the bug
TrackingCollection.Remove/RemoveAt fires the CollectionChanged event before it changes the collection.
This means it is not safe to query the collection in the event handler.

To Reproduce
Steps to reproduce the behavior:
Rough code:

var coll = new TrackingCollection<int>();
coll.Add(1);
coll.CollectionChanged += (sender, e) => { Debug.Assert(coll.Count == 0); };
coll.RemoveAt(0);  // Will fail the assert

Expected behavior
Item should already be removed when the event is fired.

Workaround
Delay any code that requires iterating or calling the collection directly when the event fires.

Related discussion

1. Not sure if TrackingCollection is meant to be used by external users. Having a CollectionChanging would ensure the correct event is fired for the correct timing (assuming you want to see the changing event instead of always changed event).
2. The set item method triggers 2 events NotifyCollectionChangedAction.Remove -> NotifyCollectionChangedAction.Add, instead of a singular NotifyCollectionChangedAction.Replace which is a bit clunky but would be considered another breaking change to fix.
3. FastTrackingCollection has the same issue.
4. TrackingDictionary has the same issue.

Start by locating the TrackingCollection.Remove and RemoveAt implementations and the related FastTrackingCollection and TrackingDictionary code mentioned in the report. Reproduce the event-handler scenario, then inspect the existing collection tests or add coverage for querying the collection during removal. Done means CollectionChanged is raised after removal while preserving the intended event behavior.