Because it isn't a new problem? Apple could have locked out Asahi at any time, but have shown no inclination of doing so. There's no reason for them to build a feature that facilitates this specific use case and then remove it in a future version.
Assuming for the sake of argument that they did, what you're left with is what you had before: having to build the process around format changes to Apple's supported process. The Asahi devs went into this project knowing that they were working around Apple's internal needs, and having to revert back to their original solution and its tradeoffs at some undefined future point isn't an existential threat to the project.
It is a huge assumption that Apple is explicitly doing anything for the benefit of Asahi Linux. Apple likely has their own reasons for doing whatever they are doing.
> Seriously, I can't think of a single reason why they'd add that for themselves. They build real Mach-Os with their own process. They have no use for raw images.
> They are saying "hey, use this, it's easier and we won't break it in the future". This is for Asahi.
Previously, the bootloader only supported loading macOS kernels. Asahi had to work around this by creating a second-stage bootloader that looked like a macOS kernel. Now, Apple has added official support for booting things other than macOS kernels -- which is not something Apple needs to do internally.
Remember, Apple spent a LOT of engineering effort developing a boot policy system that allows users to run unsigned operating systems on an M1. This is not something that came about by accident; the M1 uses an iPhone-based secure boot chain that's not anything like the UEFI-based bootloaders on x86 Macs. The Apple engineers who designed this system often hang out in marcan's livestreams and answer questions.
If Apple didn't want people to run alternative operating systems on Macs, the M1 would have been the perfect excuse to block them for good. In fact, it would have been easier to lock down the bootloader -- just use the iPhone bootloader as-is, instead of developing all the extra features needed to boot unsigned kernels. The sheer amount of effort they spent on the boot policy system indicates that they plan to keep it around for a long time.
Now, people are using Apple's custom-operating-system support to run custom operating systems, as intended. Apple engineers realized upcoming changes to macOS would break their customers' officially-supported workflows, and so they added a better workflow that won't break again in the future.
Assuming for the sake of argument that they did, what you're left with is what you had before: having to build the process around format changes to Apple's supported process. The Asahi devs went into this project knowing that they were working around Apple's internal needs, and having to revert back to their original solution and its tradeoffs at some undefined future point isn't an existential threat to the project.