Oh for sure, it just feels like something that'd have been more common in that era. While you technically could, I doubt any Linux distros out there patch the kernel's VFS in some incompatible way like this, or (more relevant) any of the BSD "distros" based on the big three.
Makes me think of all the arcane gibberish that GNU Autotools checks for, so many minor variants in system headers and APIs...
This honestly isn't that surprising. It's not incompatible per-se. Linux has plenty of ABI-incompatible kernels (-rt, -ck, -pf), plus the assortment of forked kernels which never had changes merged back into upstream for various embedded boards, intel's fork for feature development, the same for network, and so on.
One of the "big" guarantees Red Hat customers like RHEL for is that they will not break kernel ABI through a release cycle. They like this because it's really hard to do, and even very minor dot releases of the kernel provide no assurances that the ABI won't break.
This seems to be normal distro stuff, and the problem broadly seems to be in two parts:
* The Illumos team and distros need to either figure out a better mechanism for indicating minor kernel versions than the old "patch release", or they need to actually pay attention to it now that they know things diverge sometimes.
* This worked fine when building from source. The assumption that all of the IllumOS distros can freely share binary packages seems to be a bad one, and they may need to go to the same process as every other distro and actually... rebuild.
Makes me think of all the arcane gibberish that GNU Autotools checks for, so many minor variants in system headers and APIs...