Following a conversation with max.hirschhorn, it appears that while dropping a sharded collection, it is possible for CRUD or DDL events to interleave with the collection drops from the individual shards, based on their respective clusterTimes:

In the above scenario, for a single-collection stream, this will cause change streams to break in two significant ways:

• As soon as the first drop is observed, we will invalidate the stream. The insert event is therefore never seen by the client.
• If the client attempts to startAfter the invalidate resume token, then we will attempt to swallow the drops on all shards to prevent an immediate re-invalidation of the stream. However, this mechanism is based on the expectation that the next event we see after the resume point is an invalidating event. In the above case, on shard 2 we will stop swallowing as soon as we see the insert, which means that the subsequent drop on the same shard will re-invalidate the resumed stream.

In order for change stream semantics to remain robust through collection drops, there cannot be any CRUD or DDL events on that collection at or later than the clusterTime of the earliest drop event across all shards. Max tells me that this is already the case for sharded renameCollection, and that it may be possible to apply a similar approach to drop. The individual collection drops performed by the dropDatabase command should similarly obey the above constraints.