If so, I suppose that the issue is caused by the fact that the current implementation of
BindableCollection<T> does not perform AddRange as an 'atomic' action from the
Dispatcher point of view (i.e. every call to the Add method is dispatched separately, and the same goes for the final change notification). This approach avoids to stall the
Dispatcher when performing long insert operations, since the Dispatcher can execute some more code between subsequent insert operations, but could lead to problems in case the UI accesses the list before the change notification.

so that the AddRange function is 'atomic' from the Dispatcher point of view, and the UI is not notified of the change until the update process is in progress, and see if the behaviour you are experiencing is gone.

If you are interested on the topic, you can have a look at
this thread from Bea Stollniz.

I guess it would be the same as calling the BindableCollection like this :

Execute.OnUIThread(() => collection.AddRange(items));

Yes, it is logically the same! The proposed code avoids some Dispatcher.CheckAcess and shortens the function calling tree, but nothing more. :)

@Rob: I suppose that the above code (or the quick-fix proposed by kvarnhammar) would be better than leaving
the current implementation, since there could be situations where the items get even duplicated on the UI (I got this kind of problems with a similar implementation, since the collection was evaluated as changed before the notification).