ZFS is both filesystem and logical volume abstraction, so to implement different keys on different "filesystems" on ZFS, you'd need to expose them as block devices, not filesystems, and then use your encryption du jour on them, then your filesystem atop that - which also kills most of your compression or encryption properties, since you're doing it before ZFS sees the data, so to speak.
I guess I was thinking more like a 9P[0] approach where a file system can be given to a module (or any program) and based on it the module can export a related file system. For example the module would encrypt the files before storing it to the given file system.
However, I realise this does not quite fit into the current kernel architectures.
Think flexible-sized partitions. Then forget it again because it is too wrong.
The one really nice scenario this opens up that is discussed in the pull request linked in another comment:
1. Server A has an encrypted dataset in pool foo, currently not decrypted
2. A can send full or incremental streams from that dataset to server B
without decrypting
3. B can receive those streams and import them as encrypted
datasets into the pool without decrypting or really ever having
even seen the keys
4. Server A can restore from B as required
5. The owner of the key material can log into B and unlock
the dataset as if it were on A
This is a really nice, accessible way for encrypted remote backups.
Cool. As I mentioned in some other comment, I would really have to look into the details before I could use and trust such an encrypted system, to understand the guarantees provided.