There are several integration tests that hit this, marked with "TODO: SERVER-xxxx". The basic steps are as follows:

1. Shard test collection
2. Insert a document to each chunk, storing the resume token from the first
3. Drop the collection.
4. Attempt to resume using the resume token from step (2)

The expectation is that the second insert is the first result, however the change stream returns "invalidate" instead. I believe this is because mongos is not aware of the collection, so it assumes it is unsharded and only sends a getMore to the primary shard. The primary shard sees that it's next operation after the resume token is an invalidation, since the insert is on the other shard. The fix likely includes a change to the targeting logic to handle this case.

Edit: I should also mention that the behavior is different if the collection has been recreated after the drop, since mongos may target all shards in that case.