commented:

ZFS filesystem is self contained. If your OS is nuked suddently,
simply take all disks to another machine or install a new OS, install
zfs, run zfs import and get back your data.

Unless your OS was running a newer version of ZFS than your recovery
system is.  It does ask you before it lets you upgrade the on-disk
format, so it’s not exactly a footgun, but it’s still a rude reminder
when it happens to you unexpectedly (as it did recently to me).

  commented:
There is something of a footgun if you want to maximize compatibility
between OSs.  When I set up my pool on Linux, in order to maintain
compatibility with as many platforms as possible, I had to manually
enable the features supported by the lowest common denominator
platform, NetBSD:
zpool create -fd \
        -o feature@async_destroy=enabled \
        -o feature@empty_bpobj=enabled \
        -o feature@filesystem_limits=enabled \
        -o feature@lz4_compress=enabled \
        -o feature@multi_vdev_crash_dump=enabled \
        -o feature@spacemap_histogram=enabled \
        -o feature@extensible_dataset=enabled \
        -o feature@bookmarks=enabled \
        -o feature@enabled_txg=enabled \
        -o feature@hole_birth=enabled \
        -o feature@embedded_data=enabled \
        -o feature@large_blocks=enabled \
        -o feature@sha512=enabled \
        -o feature@skein=enabled \
        z raidz sdb sdc sdd

(The list of features is from https://man.netbsd.org/zpool-features.7)
I think this could probably be made easier.
.