The problem I see with current zfs.mod is that it integrates with GRUB using
the "filesystem model", i.e. each pool has one
backend (the storage device) and one frontend (the filesystem).
But ZFS is different in both ends: each pool can use N storage devices
and provide M filesystems. In the current representation this yields
two problems
for GRUB:
- zpools where more than one device is essential (i.e. not just
mirror like RAID1)
aren't accessible.

Very true, and if non-mirrored root pools are supported in the future, that
will be a problem.

- To allow more more than one filesystem in a zpool, filesystems are
selected in
a special manner, e.g.:
(hd0)/@/
(hd0)/foo@/
This collides with an assumption consistently made by GRUB utilities
and scripts: that you can construct a GRUB path by combining the result
of make_path_relative_to_its_root() (known at install time) with the device
that contains this filesystem (usually known at run time).

Well, that still does work -- you just need to modify
make_path_relative_to_its_root ;).

My impression is representing ZFS as a filesystem is doable, but not
the best fit.
ZFS is much more like what GRUB calls an "abstraction" (RAID or LVM). In fact
if you take LVM interface:
grub> ls
(hd0) (hd1)
grub> insmod lvm
grub> ls
(hd0) (hd1) (foo) (bar)
the only difference for ZFS is that (foo) and (bar) are provided directly as
filesystems (like pxe.mod does) instead of block devices for GRUB to probe.

How do you deal with multiple pools each with the same filesystem names? We
do need a namespace -- top-level should be (<poolname>) (though keep in mind
it's possible for different pools with the same pool name to exist, so we'd
need a uniquifier here also).

So my intention is to readjust zfs.mod to follow this interface. Aside from
enabling multi-device pools, this will also make it much easier to support
ZFS in the install utilities and scripts later.