I think "accidental" complexity is hugely situational and depends on the interaction between original architecture choices and subsequent maintainers of a piece of code. Good maintainers will decrease accidental complexity by eliminating it as they find it, via refactoring or other code tidyup. Bad maintainers will increase it via cut-and-paste coding, bandaid fixes, and poorly structured code.
In a long-enough-lived project, there will always be bad maintainers, so I agree that a language that eliminates accidental complexity would be great, if it were possible.
A lot of those examples seem to be related more to the amount of functionality given. For example, Xerox PARC (I'm assuming you're talking about their early desktop publishing software?) does a vanishingly small amount compared with MS Office.
Related, yes. Reasonably related? Is MS-Office really 20,000 times better at doing personal computing than what they had at PARC? Is Firefox really a 2600 times better web-browser than WWW.app?
I would say it is a stretch to say that MS-Office is 100 times better, but let's assume it is. What's the other 99.5% of the code doing? Let's say Firefox is a 10 times better browser than WWW.app. Again, what's the other 99.5% of the code doing?
There's some sort of polynomial (or exponential?) involved as we try to grow software systems, and I don't think it has to do with "bad maintainers", or at least not primarily.
In a long-enough-lived project, there will always be bad maintainers, so I agree that a language that eliminates accidental complexity would be great, if it were possible.
A lot of those examples seem to be related more to the amount of functionality given. For example, Xerox PARC (I'm assuming you're talking about their early desktop publishing software?) does a vanishingly small amount compared with MS Office.