Both drop database and drop collection coordinators are sending the drop participant command first to the primary shard and then to the others.

As a result, the current behavior permits to see the following change stream events (thanks max.hirschhorn for pointing that out):

1. drop change event from primary shard
2. insert change event from primary shard (unsharded collection implicitly recreated)
3. drop change event from other shard

It would be difficult for a client to know whether the insert (2) happened during or after the drop. Inverting the order would prevent such interleaving of events.