Ideally Google would just produce a version that was more directly update-able.
It's a little more difficult with embedded hardware, yes. But Google could create a standard source-package format and cross-compiling tool-chains to simplify this process. Or they could do something like the VESA standard for x86 to ensure you'd always have a display.
Google -> Manufacture -> Carrier is asinine. The first thing any power user does with a Windows laptop is wipe it, completely, and reinstall from his or her MSDN copy using the serial number from that laptop. Even non-power users still get all the standard Windows updates without any help from Dell, HP, etc (plus the bonus of bloat/spyware updates from said manufactures).
Even if Google didn't want to retroactively do this, they could start with Android O. It's not really in their advantage to, as it works out better for them if people have to buy new shit they don't need every two years to keep getting security updates.
Automobile manufacturers are required to produce parts for a certain number of years in support of their vehicles...
Even this is problematic, you still generate the a large incentive for the manufacturer to prevent reverse engineering of the device. If no one can find the exploits because the vulnerable firmware is not readable, the drivers are heavily obfuscated, etc, then they don't have to provide any updates and only dedicated actors with access to funds will have any chance at success.
In order to prevent this you may have to make the legislation _more_ onerous and require the manufacturer releases to the owners the ability to sign updates and reverse engineer the device. Something like this needs very careful consideration not to create perverse incentives and to maintain competition and pricing.
Can I release an annual patch for 2 super-huge bugs (let's say kernel-level RCE) found in the 18-to-6 months prior to the patch release, and ignore data leakage bugs in that time frame as well as a kernel-RCE that was found only 3 months before my release and still remain compliant?
If you do modify your device in a way that it can't be guaranteed that the updates will secure the device anymore (which shouldn't be an issue for the vast majority of user modifications), then you simply lose that "warranty" for updates, or the company is no longer responsible to keep you up to date.
But there are ways in which Google and OEMs can guarantee that for instance an OS image that's clean always resides on a locked-down partition, and that users can always "restore" their devices from that, no matter what other ROMs and whatnot they install on their devices and how many times they unlock the bootloader. The only exception to that may be people that tinker with the lock-down restoration partition as well, but for most custom ROM users that shouldn't be an issue.
So this way 99.9% of the users can still be guaranteed updates, if they want them.
I'm not saying that the updates must work on modified devices, I'm more saying that the incentive changes to preventing reverse engineering so that exploits don't happen and updates don't need to happen. Preventing that sort of user level modification, combined with heavy obfuscation and locked down firmwares does prevent reverse engineering by most amateurs and many professionals without a near-unlimited budget. If you can't read the executable for the IPC service, you can't reverse engineer it and you can't find exploits in it.
I hope this trend also eventually brings us proper no-bullshit free and open-source firmware. As long as there are organizations to request some sanity from vendors.