It's too late to (re)define GIF.

Actually software which edits animated GIFs doesn't have to crash per se, it's all about how smartly it's implemented, and because GIF editing isn't exactly a sprawling industry, most apps tend to be, well, not that smart, and so edge cases can get them.

Formats don't have to be fully implemented to their original spec for all time. If it's not serving us well today then we can change how our software uses it.

They kind of do, though, or you lose compatibility.

There are a lot of corners of the internet which just haven’t been touched in a decade. Are you going to break all of them? For what purpose?

Yes, it would be immense. Many gifs have been used for user interface elements and such a change would break that completely.

I'm not suggesting some modest, >1KB spinners should be gated like this.

Rather that renderers / apps would put a pause on downloading and processing very large (say 1MB+) or very long animations (100+ frames).

I think you are underestimating gif sizes if you think a 1MB gif is large.

but would your example, crucial, gif ui elements be that large? that seems odd

Wouldn't it be better to make a new specification that provides backwards compatibility?

If the goal is to stop obscene memory and bandwidth bloat then changing the default to a click-to-play/load would be better. My thinking is too change the incentives so producers aren't exploiting an old format to force autoplay at the expense of wasted resources and user control.

You can use <video autoplay loop muted playsinline> for an auto-playing cross-browser animated GIF replacement.