> The fact that new image formats can't be added for code maintenance reasons
Your entire premise is wrong here. A new image format is being added across all major browsers (AVIF).
So what's the distinction between JPEG XL and AVIF? On a tecnical level, it's hard to find a way that AVIF is preferrable. It's just gross. But the reality is that Apple will support AVIF and will never support JPEG XL, and an image format that doesn't work on iOS-based browsers is useless. Basically nobody will deploy it, even if it works on Chrome, they'll just continue using other formats. We know this from nobody deploying webp in a similar situation. The blood is on Apple's hands here.
Why is adding e.g. USB support useful, then? Because that's entirely new functionality, unlocking new capabilities, with no obvious fallback to a slightly less efficient older version unlike with images.
Where did you get the information that Apple will never support JPEG XL?
I haven't heard or seen anything from Apple, neither in favor nor against JPEG XL.
I would assume though that when Adobe and Serif (and their open source alternatives like Gimp, Krita, and darktable) are adding JPEG XL support in their products, there will be some incentive for Apple to add it in their products as well. After all, they do have nice HDR-capable screens now, so it would not really make sense for them to not support the best codecs currently available for HDR, which are AV1 for video and JPEG XL for still images. Apple does have a long-standing reputation for being excellent in high-fidelity image workflows, and I don't see how they would be able to keep that reputation without adding support for JPEG XL.
So I don't see why Apple can't just support both AVIF and JPEG XL. AVIF is 2-3 years older so of course they'll land support for that one first, but I don't think that should be seen as an indication that they'll not support JPEG XL.
I believe Apple will be the second major OS to add JPEG XL after Linux distros. They understand user value in the creative space. Creative work occasionally needs more than 12 bits, no surprises approach to quality, and performant lossless coding.
Perhaps that should have been worded more precisely: "The fact that some new image formats can't be added"? Code maintenance costs are the stated justification for not adding JXL. We can assume any other new image format that isn't AVIF would hit the same barrier. What if tomorrow someone comes out with e.g. a new binary vector format? Same thing. Apple may well be the real issue, but that just moves the question around (why doesn't Apple add JXL, well, probably code maintenance costs too).
It's good that they're adding AVIF, but it will presumably be the last image codec added for a very long time, especially as we face the question of who will bother researching new such codecs now. And IIUC the primary reason they like AVIF is that it's basically a video codec in image form, so again - the choice is being dominated by code maintenance costs.
So I think the wider point stands. There is already a big issue with Chrome adding features that Safari and Firefox never match. Now this. It suggests the architecture is not scalable. Why shouldn't we have as many image formats as people want to create? It's due to the desire by browser makers for everything to be in HTML5 rather than bringing back a plugin architecture.
Google can't really strongarm Apple into supporting anything. And Apple either sets the trends or follows the industry. Stop pretending Apple has anything to do with JPEG XL's imagined or real failures.
Your entire premise is wrong here. A new image format is being added across all major browsers (AVIF).
So what's the distinction between JPEG XL and AVIF? On a tecnical level, it's hard to find a way that AVIF is preferrable. It's just gross. But the reality is that Apple will support AVIF and will never support JPEG XL, and an image format that doesn't work on iOS-based browsers is useless. Basically nobody will deploy it, even if it works on Chrome, they'll just continue using other formats. We know this from nobody deploying webp in a similar situation. The blood is on Apple's hands here.
Why is adding e.g. USB support useful, then? Because that's entirely new functionality, unlocking new capabilities, with no obvious fallback to a slightly less efficient older version unlike with images.