The create/drop/collMod/(any others?) commands on time-series collections create or modify both a view document and the buckets collection entry. It is not obvious how interleaving this commands concurrently might behave. Therefore, we should create specific tests that showcase what the behavior is, and lock it in so that it does not change.

This would be very helpful for understanding our own system, and is also important so that sharding can ensure similar or comparable behavior: it's otherwise difficult to make sure sharded clusters and non-shard replica set commands will behave the same way.

It is quite difficult to understand what each individual time-series DDL operation does (no obvious high level comments), what locks are held and when (can we add lock invariants? Do we hold two collection locks on buckets and TS namespace, or serially one at a time?), along with what oplog entries are generated (I've discovered this by local testing and reading the oplog). Deterministic testing would help a great deal, as well as any additional server code documentation that can be added to highlight what's done for time-series.

Tommaso found timeseries_create_drop.js that tests interrupting create TS part way and that afterwards drop/create cmds can still succeed. It's also unclear to me how rollback behaves with partially undone create/drop/collMod commands. Additionally, how do queries and writes behave when a command only partially succeeded?