zpool bootfs restrictions when boot and root pools are different?

From: Mel Pilgrim <list_freebsd_at_bluerosetech.com>
Date: Mon, 26 Dec 2022 19:32:05 UTC
I asked this on freebsd-questions a while back and didn't get an answer, 
so I'm trying here instead.

The setup:

"bootkey" pool:
A UEFI-boot USB flashdrive with /boot on it.  It's ZFS so I can use 
copies=2 and scrubs to ensure integrity, but it was UFS in its prior 
incarnation.

"nvme" pool:
Contains the BootEnv-managed root.

The nvme pool sits on GELI-encrypted drives, and the keys are on the 
bootkey pool.  This is so the keys are never on the same devices as the 
partitions they decrypt.

This is where I run into an issue:

BootEnv uses the bootfs property to steer the loader, but I can't set 
bootfs to point to a different pool:

# zpool set bootfs=nvme/ROOT/13.1p5 bootkey
cannot set property for 'bootkey': 'nvme/ROOT/13.1p5' is an invalid name

In order for BootEnv to "work" I let it set bootfs on nvme instead:

# zpool get bootfs
NAME     PROPERTY  VALUE             SOURCE
bootkey  bootfs    -                 default
mech     bootfs    -                 default
nvme     bootfs    nvme/ROOT/13.1p5  local

and have a script that copies that value to /boot/loader.conf:

# grep ROOT /boot/loader.conf
vfs.root.mountfrom="zfs:nvme/ROOT/13.1p5"

That somewhat defeats the ease of BootEnv, but does make the rest of it 
work.  With neither vfs.root.mountfrom nor bootfs set on bootkey, the 
kernel assumes /boot is on the root filesystem then panics because it 
can't find /sbin/init.

And now the questions:

1. Why does the bootfs property restrict the value to only datasets on 
that pool if it also requires the pool name in the value?

2. Is there a way around this that would make BootEnv work without 
vfs.root.mountfrom in loader.conf?

3. If the answer to (2) is no, would it be welcome if I added to bectl 
the option to have it use vfs.root.mountfrom instead of bootfs?