Old Assumption
Most accidents are caused by operator error. Rewarding safe behaviour and punishing unsafe behaviours will eliminate or reduce accidents significantly.
New Assumption
Operator error is a product of the environment in which it occurs. To reduce operator "error" we must change the environment in which the operator works.
And: Old Assumption
Major accidents occur from the chance simultaneous occurrence of random events.
New Assumption
Systems will tend to migrate toward states of higher risk. Such migration is predictable and can be prevented by appropriate system design or detected during operations using leading indicators of increasing risk.
In the press release we see both the "operator error" and "random events" hand-waving. Regardless of the fiduciary duty of this man, this is just not good enough.
If you consider that an ecosystem evolves to the constraints of its environment, even from their pre-history at Xerox Parc, early GUI frameworks were incredibly constrained. But I think the most important constraint in their development was object orientation. Smalltalk blazed the trail for GUI programming, everyone else following after modeled their systems in that way. Object orientation became the most expressive way to program a hierarchical widget system (which most desktop systems are). Even early Windows HWND-style programming emulates virtual dispatch in non-object oriented C (also 'gobject').
In response, a vast body of knowledge and techniques around object orientation were amassed to mitigate these constraints as the ecosystem matured through the 80s and 90s. Not just patterns like MVC, Flyweight, Command et al, but also structural techniques like the event loop.
> Eventually, somewhere near the end of the 90s/middle of the 2000s, most of these things were "solved" for desktop/native, or put less charitably, they stopped changing.
So at the end of the 90s/middle of the 2000s the web browser grew out of being a document viewer into a very constrained widget kit, but the programming model was not object oriented and so the 'solved' problems needed to be solved again for a new set of constraints. Few of the traditional techniques applied, and the old object oriented way was either adapted (e.g. data binding became Redux, Flyweight/Prototype became templates) or disposed. Personally I find it a bit of a waste, but I don't expend any energy in the new ecosystem, so I don't want to be too judgy.
But I don't think desktop widget kits 'stopped changing', and are cherry-picking ideas from the browser, like 'declarative' (XAML, QML, etc) and 'responsive' (widget containers that re-flow the viewport for phone/tablet orientation etc). I hope I haven't misunderstood your question and wasted everyone's time.