I proposed will-change a decade ago when I used to work on the rendering stack at Mozilla and also tuned frontends.

In some circumstances the heads up is totally required. For example if you're on a low spec mobile device with a relatively high resolution display, you're in a situation where you can't build a layer for an animation you didn't expect. And your memory footprint is so low so you don't want to be building layers unless you need them. If you don't have the heads up then you're going to drop the first few frames of the animation and the experience is going to be janky every time.

If you're in a situation where it's not required, then I would advice against using it FWIW. I still work on optimizing web frontends and I almost never use this property because I rarely need it.

I agree that it feels like a leaky abstraction but `will-change` has been around for well over a decade now and is restricted to the animation part of CSS and I can't think of any other feature of CSS that acts similarly

I'm not sure if will-change is coding for the implementation as much as it is engaging with material reality.

If you've given up on learning, naturally your understanding of what problems have been solved (and which remain) is going to be poor.

One of the meta-solutions you've missed is the establishment of "Baseline", which helps web devs understand what features and capabilities are safe to use. I hope this helps! https://web.dev/baseline

For a good long while at least, this flag was a signal for the browser to use CPU rendering, because of the overhead of GPU setup for rendering very changing content was too high.

My knowledge is dated and second hand though. New GPU APIs hopefully changed this!

Is this true for text? Glyph rendering is complicated and I have a hard time imagining a high quality GPU renderer that can beat a CPU renderer due to this.