Every ZFS device carries four labels, two at its start and two at its end, and each label holds the pool's configuration and a ring of 128 uberblocks, one per transaction group, each pointing at the root of the pool as it was at that group. On import, ZFS reads the labels, checks that the devices it finds match the configuration, and opens the pool at the newest uberblock every device agrees on. A vdev with more members missing than its parity allows cannot be reconstructed, and because every top-level vdev holds part of every dataset, the pool is FAULTED with insufficient replicas. A device whose labels cannot be read is UNAVAIL, and the pool cannot import until it is found or the vdev can do without it.
zpool import -F is the rewind. It tells ZFS to try earlier uberblocks until it finds a transaction group that opens cleanly, and then to open the pool there, discarding every transaction group after it. -X extends the search further back; -T names a group. On a pool where the newest few groups were torn by a power cut, that is often exactly right, and the loss is a few seconds of writes. On the originals, the discarded groups are gone once the pool is written to. On images the same rewind is reversible, and the bench tries every candidate uberblock read-only before choosing.
Two dated facts belong here. OpenZFS 2.2.1, released 22 November 2023, disabled block cloning by default after a data-corruption bug was found in 2.2.0; OpenZFS 2.2.2 and 2.1.14 on 30 November fixed the underlying fault, an incorrect dirty-dnode check, which The Register reported might go back to 2006. A pool that ran 2.2.0 with block cloning enabled may hold files that are silently wrong and pass no checksum, and a pool on any version may have met the older bug under rare conditions. The other is the vdev rule: losing any top-level vdev loses the pool, so a mirror pair added to a RAID-Z2 pool for space is a two-drive way to lose the lot.