One takeaway I got from reading many articles like this over the past two years: Airplanes are a lot like JavaScript, quirky and full of gotchas, and what the p

One takeaway I got from reading many articles like this over the past two years: Airplanes are a lot like JavaScript, quirky and full of gotchas, and what the pilots rely on is being well-informed and having access to good documentation on the evil. Everything seems to rely on a complex system of diseminating errata through bulletins, checklist and manual updates and training. The best airplane might not be the most bug-free but the best documented and most well-understood. The worst airplane may be the one with the most undefined or unknown (by pilots) behavior. Part of what made this such a fiasco is that the behavior and interactions of these systems were purposely not documented and kept not just from the FAA, but pilots in particular. This meant they had no chance to do their job well and operate the equipment correctly. Add to this manufacturers reaching for "pilot error" quickly and as a pilot I'd imagine being rather pissed off. This seems interesting with the 737 in particular: It's been around for a long time and was probably considered well-understood. Boeing introduced the MAX telling everyone "it's still the same", and then threw pilots one gigantic (as well as defectively implemented) curveball. Instead, deviations from and additions to a well-known system should have been pointed out and documented especially well. It also seems to suggest there must be a system complexity ceiling where pilot recall of checklists and subsystem interaction permutations fails to scale anymore, and the addition of new systems probably needs to be evaluated against that notion. Assistance systems like MCAS are supposed to make things easier - but their edge cases and interactions potentially carry a "recall tax". Another pattern I see in articles like this (another example is the A380 engine failure in I think a Quantas plane years ago) is that planes rely on informing pilots of subsystem state through what's basically a stack of notification message dialogs with the goal to get pilots to explicitly confirm/react to each one, but that means by the time the pilot has time to work through the stack during a crisis the content may already be outdated, or there's no time to tend to the stack to begin with. There may be better UX designs possible such as master system diagrams with status? Dunno. Note: I'm a layman, and in topics like this I feel uneasy whenever I relay or suggest what may be based on wrong assumptions.