Seems like there is a problem with using Magisk Canary with a non-stock kernel. Freak told me "Magisk changed the way verity is handled during the canaries and that's why things will change."
I was hoping that this Kernel might work with Magisk Canary, but that does not look to be the case.
Again, the problem has nothing to do with any of the kernels itself.
On pixel 6 devices flashing a custom kernel involves flashing 4 images to your device. boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img.
Simplified explanation:
Essentially with vbmeta flags for verity/verification enabled on your device, if you flash a source built boot.img, which contains an exact replica of the zImage from the "stock" boot.img the device will fail to boot due to verity not matching the original boot.img from the stock firmware.
Initially when the Pixel 6 just released, magisk did not have the "ability" to work around this check. So everyone that wanted to root their devices needed to disable this check (this is what disabling the vbmeta verity/verification flags does), as patching a boot.img with magisk alters the boot.img so it´s no longer a "stock" boot.img. Additionally with vbmeta flags disabled you´re able to flash other source compiled images to your phone, that are not stock which would trip the vbmeta check otherwise.
Then Magisk added the ability to disable that check by patching fstab. That enabled users to no longer having to disable the vbmeta flags when rooting their devices via a patched boot.img. As a side effect, this also enabled users to flash other non stock images to their devices without tripping the verity check if rooted with magisk. (this is the current state in magisk stable 24300)
Recently magisk was reworked and no longer patches fstab to work around verity. So while you´re still able to root pixel 6 devices without disabling verity flags by just modifiying the boot.img via those recent canaries(by magisk patching it), flashing a custom kernel will no longer work with vbmeta flags enabled while running canary, as it involves more partitions than just the boot.img. (this is the current state in magisk canary)
I´m not sure if Magisk considers this an "issue", as magisk in itself is not impacted in any way by this change.
It´s a very unfortunate change for anyone that wants to run a custom kernel and now kept vbmeta flags enabled over the last months. So essentially this might require falling back to the original method of keeping the vbmeta flags disabled each month if not other easy workaround this found.