Problem

A leader can drop a layered table and then create a new table with the same name. When a follower picks up a checkpoint that includes both changes, it finds a name it already knows, now belonging to a different table. The follower currently refuses to pick up such a checkpoint and halts. That guardrail, added under WT-18068, stops the follower from confusing the two tables, but it means a valid sequence of operations on the leader stops the follower.

Expected behaviour

The follower should do what the leader did, as it does for every other change it picks up: drop its copy of the old table, then pick up the new one.

Why this is not done today

Dropping the old table during pickup can fail while the table is still in use by readers or writers, including the oplog applier. A pickup that fails must leave the follower exactly as it was so it can simply be retried. Today it can't, because a table drop that has started cannot be undone.

Possible approaches

• Make the drop safe to fail: split it into two phases, where the first acquires everything the drop needs (for example, all of the table's handles) so the second is guaranteed to complete; or make the drop undoable, so a failed pickup can be rolled back completely.
• Make drop behave like a Unix "unlink": existing readers keep the old table while new opens of the same name get the new one. With that in place this case becomes almost trivial.

Context

MongoDB does not re-use table names on followers today, because each table is created by exactly one replicated operation and the oplog is applied before a checkpoint is picked up. It is still worth fixing, because the protection rests on that convention rather than on WiredTiger, and tests have to be written to avoid this sequence.
WT-18284 covers the leader's side of the same create/drop/create pattern; this ticket covers the follower picking it up. WT-18068 has the history and reproducers.