I'm working on trying various differing work-arounds with what is there natively.

I tried building the newest git on Grub2 2.12. Fails building at a point which is says way fixed for the error i am getting, but still fails on the make at the same point. (asorti ot defined)

I'm also working on another theory, recreating bpool with differing options, on the theory that on the creation of bpool, that some on the zpool options are causing Grub2 to fail with those added challenges.

I'll keep you up-to date how those go. Trying to balance my time between "real life", helping the upstream Intel Graphics Support Engineers with drivers issues with Ubuntu, and helping Users with other issues. ...All while trying to find underlying information answers for this issue.

I know in the ZFS install scripts, when I was tracing the process of that, for bpool, it says compatibility grub2, and features all (or something to that affect)... but some features being enabled are causing this problem after snapshots are being taken on bpool.

This is why I am pursuing this and testing what is going on with that... If that is true, and if the new Grub2 patches fail, then there is a much bigger problem there with far more reaching implications on what has been installed as ZFS (to correct it). ...And for changing ZFS feature settings in the installer for Noble, BEFORE it's release.

I think if that is true, then a new compatibility option named ubuntu24.04 can just  be set to set the allowed options of the correct disabled feature options, then nothing would have to change in the installer script for Noble. That would take care of all that for new installs. That compatibility option would need to be added to ubuntu-desktop-installer image, then to the ZFS installer script as "option compatibility=grub2,ubuntu24.04"... 

What get's me, it that "feature" or "ability" that this is failing on, being able to snapshot bpool, because that is the failure point we need to protect from, was covered by Zsys, and why Canonical came up with that in the first place. It worked in 20.04 LTS... There was not a problem there, with that installed. We were able to do that in that release. Marketing-wise, it put Ubuntu ahead of things with that "need" covered well.

Zsys was removed from being a default install (no mention why), but I still see commits to it. The need to make snapshots of the boot related files is still there. I wish I knew more on the why Zsys fell from favor. I thought basically, besides some minor needed config and customization changes, it was a great idea to do what it was intended to do.

Some users, have gone around this problem by using ZFS Boot Menu (ZBM). But that is not a solution, Rather it removes the conditions, by what they have to do in the restructure to make it work. For it, bpool cannot exist. There cannot be a separate /boot. /boot has to be inside the root pool, and not inside it's own ZFS dataset... If this restructure is done this way, then those conditions do not exist. That is why is works. No that ZBM gets around the problem itself. If you crate a dataset for /boot itself, to make snapshots of boot related files, then ZBM does not work, even before the snapshots are made. It simply cannot find the boot related files, that way. (At all.) So to do a snapshot of boot related files, after that restructure, you end up having to snapshot the (whole) root pool,  

No, we need to find a way to get Grub2 and ZFS to play together nicely, and be stable.