What I find most surprising about deprecations and removals in Chrome, is they often don't seem necessary as they could have been done less disruptively. Sometimes they seem to be poorly thought out changes that are being forced through. Naturally in this case as a web developer my inclination is to resist. But it's difficult to feel heard when trying to suggest something less disruptive that still achieves the same goals; often it feels like it's too late, the decision has been made, and we're all being told to just deal with it.
The change to Web Audio is a good example. It could have been done backwards-compatibly: just mute the page on startup, and automatically unmute it on the first user input event. Legitimate content would keep working with no changes, albeit starting off muted. Abusive content still can't play audio straight away. The goal is achieved with no API changes and no need to tell the entire web to update their Web Audio code. Why did it get done in a breaking way? Did Google even consider this as an alternative? I never found out. But I do know that all our code got broken, we had to go and update everything, tell our customers to re-publish content, and then Web Audio is permanently more complicated to use for all developers in future. Without knowing why the less disruptive route wasn't taken, it's hard not to feel it was a mistake, and if anything I wish I argued against it even more forcefully than I did at the time.
Moving on to the process of removing JS dialogs, why not confine them to only appear in the frame that created them? Those frames can already show arbitrary content, including trying to misrepresent themselves. If the dialog can't escape the calling frame, it should prevent any confusion over the source of the dialog, as it is no longer possible for an iframe to display a dialog over the top frame. This would keep full API compatibility for most legitimate use cases. It might break some cases where invisible iframes expect the user to be able to dismiss a dialog. However that would be far less common, and probably include a much greater proportion of abusive use cases that we all actually want blocked. And then you wouldn't be doing things like breaking coding tutorials all over the web. Why was this approach not taken? I can't tell. Again, it just seems like a mistake, and I haven't seen anyone from Google justify why removal of a decades-old web platform feature beats changing the implementation to prevent abuse or confusion (please do correct me if someone has explained this). The impression is of Google forcing through their own decision without any scope to reconsider a better alternative, so naturally the inclination as a web developer is to resist it. Luckily Google seems to have backed down this time - maybe there is a chance it can be done differently after all - but worryingly it looks like it's only a postponement and we'll still get the same breakage in the end.
At a minimum I think Google needs to do more to communicate what alternatives were considered and why they were not chosen. If you're going to cause compatibility nightmares for web developers at Internet scale, you better have a good reason, and too often it seems like the reason isn't good enough. And consider that if you make an announcement and there's a significant backlash, perhaps it really is a mistake after all, and you should try something different.