Well, it is relevant whether Google cares about things or not especially if you are only interested in stock, as there is a lot less you can do there.
It's the bootloader stupid. Apparently Android 12 bootloader requires AVB-2 and verity in orange state.
The reason it happens on newer Pixels only has to do with the Android version these devices came out originally. Devices that didn't come with Android 11 originally have legacy bootloaders. Such devices were converted to Android 11 with their bootloaders still backward compatible with Android 9. Pixels 4/5 probably came out with Android 11, so, they are only compatible with Android 10.
Anyway, the only thing you can do is try to extract Android 11 bootloader from stock and flash it on your device that has Android 12.
It works on Oneplus 6/6T, which were recently updated to stock Android 11. That update broke TWRP, However, when you flash Android 10 bootloader on stock Android 11, all problems disappear.
Not sure if you're calling me stupid or the bootloader stupid, either way you should be careful about the insults.
My point on relevancy is that it doesn't change the issue we are dealing with - I agree in that I don't think Google is interested in preventing root, but I do think that they implemented new features that had the unintended effect of what we are dealing with here.
I don't think this is a bootloader issue, because the bootloader that shipped with 210812.015 (A12 initial public release) is the same as 210812.002 (A12 beta 5) - and as I mentioned previously, all we had to do on Beta 5 is flash vbmeta with the disable flags.
And, against my better judgement, I tried flashing the A11 bootloader. Unsurprisingly, I got the corrupted system error. I'm not sure where you got your information; bootloaders are typically backwards compatible, but systems are not - you can run an Android 9 ROM on an Android 11 bootloader, but you typically cannot do the reverse.
Not to be rude but it seems like you're basing your comments on incorrect information, or at least information that is relevant to a different device. In this specific case, the Pixel 5 bootloader only handles one part of AVB - verifying the kernel against vbmeta as it loads. If it doesn't match, and verification is not disabled, the bootloader will halt and display the "Unable to load/verify boot images" message.
But we aren't dealing with that. We already discovered this on the 12 beta and discovered that using --disable-verification and --disable-verity turns off this initial verification.
The issue we are running into now, as I have tried to explain exhaustively, is that the
kernel begins to boot, but something in the kernel itself - probably dm-verity - finds some sort of mismatch, regardless of the bootloader state, has a kernel panic, reboots the device, and boots into recovery mode with the data corrupted error.
So what I believe we need to do is disable verity in the boot.img itself. I'm going to fire up a hex editor and
use this guide, specifically Method 1, to see if I have any success.