I don't know what gave you the impression that illumos would be dead, but it's Oracle Solaris that was practically dead after they closed it down and every key developer left and none of the key technologies had any major advancement since. Oracle ZFS even has outstanding bugs/quirks/limitations that have been resolved years ago for OpenZFS. Lots of features aren't even available because Oracle can't include the CDDL-Licenced code into their ZFS.
Oh, and Oracle is about to do what they did with any good and healthy company/software/project they assimilated after letting it starve and rot for a few years:
https://www.thelayoff.com/t/KBEVoB1 So no Solaris 12...
The Illumos community might be a lot smaller than even the FreeBSD one, but it's healthy. Quite a few companies build their whole business on top of illumos and very actively drive the development forwards. E.g. Delphix, joyent or nexenta come to mind, with major contributions to OpenZFS like persistent L2ARC (and other ARC/L2ARC improvements) from nexenta or LZ4 compression from Delphix.
Have a look at the feature list and when they were avalable on each platform:
http://open-zfs.org/wiki/Features Most features were implemented first on Illumos and shortly after on FreeBSD, with some being implemented in paralell.
I think we are drifting way too OT here; so to contribute at least something useful to the initial topic:
I've had a small hickup with migrating a pool from debian linux (pool created 8/2015) to FreeBSD 11.0-RELEASE. For convenience (downtime) reasons I wanted to just
zfs send -ReD some datasets to get most things running on the new box prior to killing the old one and moving the whole pool to the new system. It seems the Deduplication for streams is either _very_ slow or somehow broken for ZoL, as the system firstly took very long to even show any load, taking ~10 minutes until a stream started trickling out, that was immediately aborted by the receiving side. On any FreeBSD system
zfs send -ReD immedeately trashes the disks, grabs any RAM it can get, starts the dedup process and shortly after starts sending the stream.
Omitting the deduplication worked as expected (with a much larger stream though).
Importing the pool on FreeBSD worked without any Problems;
zpool import -N was everything needed. After moving the data to the new pool I even tested updating the pool, which worked just as expected. (I destroyed the old pool and the partition tables afterwards to add the disks to the new pool, so no "long-term testing")
