With no codec for a new compression algorithm, it does not matter if the browser can read the container, you still see the "broken image" icon on your display.
You as user can then upload AVIF images to wherever images on the site are processed. And after that, let's say when newer codec inside AVIF will get a good browser coverage, you'll be able to start using it without waiting another decade for GitHub to pipe it through their site code.
For formats without a container, it's always a two step process. Browser coverage first, then another huge period of sites support catching up.
> You as user can then upload AVIF images to wherever images on the site are processed
Those image upload pipelines almost always process the image in some way (downscaling, compressing). So a new codec in the same file format can only break them.
But even if it didn’t, I can’t help but view this as a dependency hell. Somebody uploads a version of AVIF not yet supported everywhere. Things break. User doesn’t understand why, because user doesn’t understand that .avif != .avif. Developers have a hard time figuring out why, because they have to check all software touching those files and check what specific codecs or version those support for AVIF. And all they can do anyway is to wait for all affected libraries or software to roll out the new codec.
So I guess in other words, the codec is the file format.