The usr hook isn't what needs fixing here.

Does blkid detect the filesystem properly? Does 'zfs' appear in /proc/filesystems?

blkid shows TYPE="zfs_member" for disk partitions that are members of the ZFS pool.
zfs is listed in /proc/filesystems.

Hmmm... so what happens when you try to mount it without the -t flag? Can i get the output of:

LIBMOUNT_DEBUG=0xffff mount /dev/whatever /new_root/usr

mount command says "you must specify the filesystem type" when mounting without -t option.

# LIBMOUNT_DEBUG=0xffff mount OS/usr1 /mnt
libmount: debug mask set to 0xffff.
16085: libmount: CXT: [0x1124060]: ----> allocate
16085: libmount: UTILS: mtab: /etc/mtab
16085: libmount: UTILS: /etc/mtab: irregular/non-writable
16085: libmount: UTILS: utab: /run/mount/utab
16085: libmount: CXT: [0x1124060]: mount: preparing
16085: libmount: CXT: [0x1124060]: use default optmode
16085: libmount: CXT: [0x1124060]: OPTSMODE: ignore=0, append=0, prepend=1, replace=0, force=0, fstab=1, mtab=1
16085: libmount: CXT: [0x1124060]: fstab not required -- skip
16085: libmount: CXT: [0x1124060]: merging mount flags
16085: libmount: CXT: [0x1124060]: final flags: VFS=00000000 user=00000000
16085: libmount: CXT: [0x1124060]: mount: evaluating permissions
16085: libmount: CXT: [0x1124060]: mount: fixing optstr
16085: libmount: CXT: [0x1124060]: mount: fixing vfs optstr
16085: libmount: CXT: applying 0x00000000 flags to '(null)'
16085: libmount: CXT: new optstr 'rw'
16085: libmount: CXT: [0x1124060]: mount: fixing user optstr
16085: libmount: CXT: applying 0x00000000 flags to '(null)'
16085: libmount: CXT: new optstr '(null)'
16085: libmount: CXT: [0x1124060]: fixed options [rc=0]: vfs: 'rw' fs: '(null)' user: '(null)', optstr: 'rw'
16085: libmount: CXT: [0x1124060]: preparing source path
16085: libmount: CXT: [0x1124060]: srcpath 'OS/usr1'
16085: libmount: CACHE: [0x1124290]: alloc
16085: libmount: CACHE: [0x1124290]: add entry [ 1] (path): OS/usr1: OS/usr1
16085: libmount: CXT: [0x1124060]: final srcpath 'OS/usr1'
16085: libmount: CXT: [0x1124060]: preparing target path
16085: libmount: CACHE: [0x1124290]: add entry [ 2] (path): /mnt: /mnt
16085: libmount: CXT: [0x1124060]: final target '/mnt'
16085: libmount: CXT: [0x1124060]: FS type: (null)
16085: libmount: CXT: [0x1124060]: prepare update
16085: libmount: UPDATE: [0x1124f10]: allocate
16085: libmount: UPDATE: [0x1124f10]: resetting FS [fs=0x0x1124150, target=(null), flags=0x00000000]
16085: libmount: UPDATE: [0x1124f10]: FS template:
16085: libmount: UPDATE: ------ fs: 0x1124150
source: OS/usr1
target: /mnt
fstype: (null)
optstr: rw
VFS-optstr: rw
16085: libmount: UPDATE: prepare utab entry
16085: libmount: UPDATE: utab entry unnecessary (no options)
16085: libmount: CXT: [0x1124060]: mount: do mount
16085: libmount: CXT: [0x1124060]: trying to mount by filesystems lists
mount: you must specify the filesystem type
16085: libmount: CXT: [0x1124060]: <---- reset [status=0] ---->
16085: libmount: CACHE: [0x1124290]: free
16085: libmount: UPDATE: [0x1124f10]: free
16085: libmount: CXT: [0x1124060]: <---- free

Oh. So ZFS devices aren't legit devices in that they're magical things that get pulled out of thin air rather than the pool itself existing as a block device in /dev. Annoying. 9p does this as well.

Well shit. I guess I have to fix this in the usr hook.

...But I will point out that you can work around this by adding 'zfs' to /etc/filesystems. Not sure if it's intentional that /proc/filesystems isn't read by mount when /etc/filesystems doesn't exist.

edit: and mount(8) confirms that /proc/filesystems should be read if /etc/filesystems doesn't exist. Wohoo.

edit edit: Hmmm, so mount from latest util-linux git will indeed read /proc/filesystems, but it only tries filesystems which aren't marked as nodev (which zfs and 9p probably are). So, the u-l fix doesn't even save me.

This will be fixed in the zfs-utils AUR package. I'd rather lean on mount to figure out what the filesystem is, helping it along where necessary. Maybe in the future I'll add a usrfstype= flag to the kernel cmdline in case you really want to override the auto detection.