What really matters when dealing with ZFS pools and datasets portability is their versions. You can always import a pool using a version less or equal to the one your OS supports, and the same rule applies for datasets (i.e. file systems, zvols and snapshots).
So if you plan to move ZFS pools from some OSes to different ones, make sure you select the largest common version for pools, file systems and zvols you want to share. eg:
zpool create -o version=28 -O version=5 ...
Beware too that the Open Source branch of ZFS introduced "feature flags" which, when enabled, make the pools incompatible with Solaris. They set the pool version to 5000. On the other hand, feature flags were designed to allow some flexibility when moving a pool to an OS not supporting some features.
About architectures, ZFS objects are written using the native bit ordering of the platform. This is not a problem as all ZFS implementations are able to read both big endian and little endian objects. The endianness is stored along with all data structures. There is then no issue importing a pool from say x86 to SPARC and reciprocally.
Finally, you might have issues when dealing with pools built on non whole disks. The target OS must be able to understand the source disk partitioning. The worst case scenario would be if you create a pool based on plain files (which is not recommended outside testing) and the file system used cannot be mounted on the target platform.