the point of the article (just as with the one about names) is that there are "reasonable defaults" many people would believe - that don't work in practice and become gotchas
whether you have enough knowledge to know that something is unreasonable doesn't mean it doesn't seem reasonable for many others
And as programmers, we inevitably spend most of our time dealing with these weird edge cases, because the stuff that makes sense is generally incorporated into our initial modelling and becomes a solved problem.
It does. The distinction between a misunderstanding of aviation, or a misunderstanding of which of many possible models is in place.
I'm interested in misunderstandings of aviation. How did aviators think about it before software ever entered the picture? Which of their concepts are coherent, and why do they use them? What reasoning power do those concepts get them? It's interesting when programmers misunderstand that.
It's less interesting when programmers setup a poor system for keeping track of things. It could be busses or trains or parts in a factory. It's not aviation specific, and it's run-of-the-mill bad design when it's done badly. Apparently the first software engineers to model aviation were really bad at it.
it doesn't matter whose failure it is
the point of the article (just as with the one about names) is that there are "reasonable defaults" many people would believe - that don't work in practice and become gotchas
whether you have enough knowledge to know that something is unreasonable doesn't mean it doesn't seem reasonable for many others