That is clearly not true, when does a game that worked one day to stop working the next day on for any native desktop program, or on a mobile or console platform?
The only conceivable time that I could imagine it happening is when my phone does a major version update, which happens a maximum of once in the entire phone's lifetime, is very visible to me (it would be clear to me that it isn't completely the developer's fault), meanwhile chrome updates every week silently. If any website works one day and not the next I would always assume the developers had pushed a bad build.
How about when an OS ships an update? A library you're using (you didn't write that whole audio and gfx layer yourself, did you?) ships an update? A crippling bug gets exposed in some API you use? This is by and large not the first time we've run into problems like this before--is the Internet's memory so short that DLL Hell is a forgotten concept? Any time you rely on any third-party code anywhere you run the risk of something working one day and not the next, just by virtue of an update.
You explicitly are talking about historical issues which are mostly resolved. When you deploy an application that uses Direct X you target exactly one version, and you will never be using a different version of it unless you as the developer choose for it to happen.
OS shipping updates causing games to break is a pretty rare thing, several orders of magnitude less likely to occur than a browser shipping with a change in behavior of an HTML5 feature.
The risk clearly does exist everywhere, but its mostly a solved problem on Windows, and it's certainly a solved problem on Xbox. It's a monthly issue in browsers.
Historical issues for who, exactly? The way it was solved was to keep a copy of every DLL ever released on your system--I don't exactly call that solved; it's more like treating a cold with medicine that stops you from coughing (you're no longer coughing, but you're still sick). You can't really expect to use that solution for all possible situations.
It's absolutely unacceptable to keep around support for every version of HTML and JavaScript and CSS ever, especially when some of the versions are contradictory. The real solution is to make a clean break, learn from your mistakes, and do it better the second time around. Unfortunately, that means losing a lot of content if you can't automatically update it to new formats.
As for being a solved problem on one specific and unchanging platform, that's like saying networking is a solved problem so long as you stick to TCP/IPv4 and never have more nodes than you can have addresses. That's not a solution, it's a cop-out. Requirements change, specifications change, and most certainly, performance characteristics change.
As for being a solved problem on windows, the solution is just as bad as the problem--the difference is where the pain point lies. On my w7x64 machine, the windows folder takes up somewhere around 15gb of space (I don't have it handy to check the exact amount). That is absolutely unacceptable for an OS without any applications installed.
As for being a "monthly" issue for browsers, how frequently do you think it was an issue for major OS vendors until the specifications were finally more-or-less set in stone? Because I assure you, it did not happen overnight.
You are literally describing a solution, it might be a solution that you don't like but it is a solution that makes it so developers don't have to worry about random things breaking for no reason. AFAIK the solution is to have the applications install the version of the dll that they use, if Windows is 15gb with no applications (which seems like an exaggeration to me) then I think that is largely incidental.
> for major OS vendors until the specifications were finally more-or-less set in stone
Again explicitly invoking historical events.
> It's absolutely unacceptable to keep around support for every version of HTML and JavaScript and CSS ever, especially when some of the versions are contradictory
That is totally fine, but it makes browsers something that no developer other than bleeding edge early adopters and crappy social media game developers can reasonably support.
No one cares if they are as painful as desktop development was 15 years ago, developing for 1997 desktops isn't an option today, my entire point is that developing games on the web today are like developing games in 1997 which is awful. In 1997 you had no other choice; the options are any of a dozen mature platforms (desktop, mobile apps, consoles, handhelds) or else trying to juggle about 6 wildly incompatible and buggy browser environments where all of them are either too old to even support features that you want, or else a moving target that is changing literally every week in a way that is transparent to the user, which means you get blamed for the breakage when you could have done nothing to avoid it.
The only conceivable time that I could imagine it happening is when my phone does a major version update, which happens a maximum of once in the entire phone's lifetime, is very visible to me (it would be clear to me that it isn't completely the developer's fault), meanwhile chrome updates every week silently. If any website works one day and not the next I would always assume the developers had pushed a bad build.