When a node steps up, it recreates the stable constituents that are missing locally from the entries in the shared metadata operations queue, in __layered_create_missing_stable_table (src/conn/conn_layered.c). The configuration it builds merges the table_meta defaults, the layered table's configuration and log=(enabled=false), and nothing in that merge selects the disaggregated block manager. The row it writes can therefore record block_manager=default, while the same table in the shared metadata records block_manager=disagg.

A stable constituent has to be disaggregated: with the default block manager the node reads and writes that table through its own block manager instead of the page log, so anything it writes there after stepping up is invisible to the rest of the cluster.

The immutable-field validation in checkpoint pickup is what makes this visible today. A later pickup compares the local and the shared entry and panics:

checkpoint pickup metadata mismatch for "file:schema_0_3_48.wt_stable": the value of
"block_manager" differs between the local ("default") and the shared ("disagg") metadata

Reproduced with test/csuite/schema_disagg_abort on a two-node role-switching run:

./test_schema_disagg_abort -b <build> -r lf -s 3 -t 25 -T 8 -u 64

Note this needs the WT-18068 work in place: without it the same run dies earlier on the create/drop/create btree ID panic, before any step-up rebuild happens.

Worth checking as part of the fix whether the rebuilt row agrees with the shared entry on every immutable field, not only the block manager.