When a tiered storage btree is created, a metadata "file:" entry is created (in addition to other entries), and over time, "object:" entries are created.  Basically every flush_tier operation effectively transitions a "file:" entry to an "object:" entry, and creates a new "file:" entry.

But - unlike the non-tiered world where a table: and a file: have a similar relationship and you can open a cursor on either a table: or a file: and get sensible results - you cannot (or maybe should not) open a tiered file: cursor and get something sensible. The easiest way to explain is that the tiered "file:" does not have a checkpoint (or maybe it still has the checkpoint when the file: was originally created.  Its checkpoint is not updated, rather the "tiered:" entry is the root of the "whole" btree and where all of its checkpoints are kept.

Possibly a better solution is to make that .wtobj file on disk into an "object:" in the metadata, and have a flag that says it is on disk.  If that doesn't suit maybe "wtobj:" or "fileobject:".  Otherwise I think we'll be open to weird bugs and/or we'll need strange workarounds.