Dropping a layered table mutates the shared metadata queue before the local drop can still fail (e.g. EBUSY from open cursors): the REMOVE is enqueued. After WT-17091, a never-published table's queued CREATE entries are canceled - ahead of dropping the local constituents in __drop_layered.

Consequences of a failed drop:

• The enqueued REMOVE persists while the table still exists locally. A subsequent checkpoint covering its epoch removes the table from the shared metadata while it is still live.
• For a never-published table, the CREATE cancellation has already happened; a successful retry of the drop then finds no CREATE to pair with and enqueues a bare REMOVE@UNPUBLISHED - reintroducing the lingering-REMOVE shape that blocks follower pickup of a same-name table (fixed for the non-retry path in WT-17091).

This is a pre-existing error (predates WT-17091).

Suggested direction: perform the queue mutations only after the local drop has succeeded, or roll them back on failure. Mind the lock ordering (queue mutations require the schema lock, which the drop path already holds) and the metadata-capture requirement (the REMOVE entry snapshots metadata values before local removal, so a reorder must capture first, enqueue last).