I can't think of many new browser features I've used in the past few years. There's the permissions API and the fileReader API that are part of apps I've built (and they're very useful), and I've played with a few things like sharedArrayBuffers and WebGL2 but not in anything that's been deployed. Browsers do move fast, but not that fast, and most of the new features are super niche things that the majority of developers don't really need.
If you're prioritizing looking at new things over accessibility and cross-browser support then you are making that choice; browser vendors are not forcing it upon you.
The one feature I want more than anything in the world (and seems to be stalled in Chrome land, which means it’s stalled overall since chrome tends to drive the standards) is the streams API (aka websockets with backpressure). There’s no easy way for clients to signal to servers that they’re overwhelmed, and the result is either saturating the network or the CPU since the message handlers are synchronous.
Yes, and this is what really bothers me. Feature detection is a thing in browsers. There's things like @supports in CSS, "if (<property> in <API>)" in JS, and there are even whole libraries like Modernizr to make it trivial to detect whether something is available. Web developers don't bother though, and then they complain that "browsers broke their code".
Browser vendors do a lot to make it possible to write robust code that doesn't break in the future. Maybe they could do more, but if web devs are failing to leverage the features that are there already then why would they? A whole lot of the responsibility for the broken ass nature of the web is not due to browsers.
For instance Safari on iOS reports support for drag and drop events, but they aren't actually triggered. Another I encountered recently is the "accept" attribute on input file type. On iOS, you can't set specific file type, just mime type, but you have no way to detect that except by using the user agent. Then you have the buggy releases that make a feature seemingly supported, but is actually unusable in practice (looking at you IndexedDB on Safari).
This means using a library like Modernizr is almost mandatory. Also, what do you feature-test? Everything? Feature-testing something that has been available for 20 years sounds like a waste of time on the face of it, but the "alert" case has shown us that if you really want to do it correctly, you can't assume anything.
I am not saying it is not possible to do it properly, but it is not that simple. For anything non-critical, I understand waiting for things to break then fixing them instead, it's way less efforts.
The fact that all three examples you listed are iOS Safari is giving me flashbacks to a previous job where we had way more time spent coming up with ugly hacks to make iOS Safari like something behave closer to a decent browser than we spent on all other areas of new feature development. And we also supported IE11, which was way easier to manage specifically because it didn't straight-up lie to feature-detection like iOS Safari did (and does).
It's probably a bit biased because I develop on Firefox/Chrome (very rare to find difference between the 2) and have to wait for reports/borrow an iOS device to test/debug. There might be similar issues with the aforementioned browsers, but the pain is less visible because it happens during development and I don't remember it. Also most of our users are using iOS devices, so reports for them are more likely. On the other my gut feeling is that iOS is more painful to develop for.
I'd argue it's very much on the browser vendors, because they create the strong expectation that everyone is supposed to always be using the latest version. They do this by bundling together feature updates and security updates. Web devs do the pragmatic thing and ignore feature detection, because they know users are constantly being told to update their browsers to keep themselves safe.
If you're prioritizing looking at new things over accessibility and cross-browser support then you are making that choice; browser vendors are not forcing it upon you.