Here's an example of this race:

1. A standby or PIT restore node fetches oplog entries where dropCollection and dropIdent are not too many oplog entries apart (for example, on an idle cluster the primary can generate oplog where these two sit close to each other). And for whatever reason (PIT restore, or a standby catching up on a backlog oplog entries), the oplog entries are processed very quickly wall-clock time wise of each other. This is what we see in this test.
2. The oplog writer writes all of these oplog entries into the oplog, and then pushes the entries to the oplog applier's buffer.
3. The oplog writer runs again, and when it does, and it does AutoGetOplogFastPath:
   1. (Please correct me here) AutoGetOplogFastPath gets a reference to a version of the catalog at this moment where the collection hasn't been dropped yet
   2. We are therefore holding a reference to a version of the catalog which has a reference to the collection and from there, a reference to the ident.
4. The oplog applier processes the oplog entries and executes both oplog entries in their own batches. The important point here is that the oplog writer is holding a version of the catalog that has a reference to the ident, and so that's why the invariant that the ident has expired is failing.

I think it doesn't happen on the primary because we only try dropping the ident if it's expired. The standby / PIT restore node is different because it just "has to do" what it sees in the oplog regardless of whether another reader is holding the ident.

I also wonder what would happen if there's a reader (user) holding the catalog that started right before the dropIdent. Will the standby crash for the same reason?