Bro... 🥺
The concern about ABI stability is valid — but the thing is, libzfs is not a stable interface in the first place.
As noted here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257222#c1

libzfs symbols are explicitly not guaranteed to be stable, the same zpool shows different fragmentation values on Gentoo and FreeBSD, and even within the same OS family (e.g., FreeBSD → TrueNAS), the ABI breaks frequently, including changes in internal struct layouts and symbol visibility.

So saying “this breaks ABI” is somewhat moot, because the whole module already relies on an ABI that upstream ZFS developers do not intend to keep stable.

Regarding NetBSD being niche — I agree it’s not a mainstream platform, but that's precisely why a simple, command-output-based fallback (zpool get -Hp ...) is a safer option than maintaining a separate set of libzfs headers for each OS.

If the goal is long-term maintainability, relying on zpool output (which is stable across Linux/FreeBSD/NetBSD/illumos(sunos)) is arguably more robust than relying on libzfs internals.

If full libzfs support is considered too fragile or high-maintenance, maybe it’s worth discussing whether the zpool module should:

• use libzfs only where it’s reliable, and
• fall back to parsing the CLI elsewhere, or
• rely entirely on CLI output for consistency across platforms.

I’m not advocating removing the module — ZFS users exist on all these platforms — but the current situation already depends on unstable APIs, and a CLI-based approach avoids exactly the ABI issues being pointed out.