> a specific edge case in the AoA cross-check logicWhat the article you linked to describes doesn't look quite like that to me. It looks like a design that does not use the "median of three values" method that the article says is used for "most" sensors (but not AoA). I agree, however, with your correction that it was not a direct AoA sensor failure such as occurred in the 737 Max incidents.
> It's undoubtedly a serious design flaw, but it's not even remotely in the same ballpark as the Max's flagrant disregard for all process and well known design standards.
It's not the same as MCAS in the sense that it's not an ad hoc addition to deal with an issue that arose in a redesign of an old airplane, true.
However, it is a case of (a) a flaw in an automated system causing the plane to automatically take an action that is unexpected and dangerous, instead of the automated system detecting the error; and (b) an automated system overriding the input of the human pilot in a case where the human pilot can plainly see that the automated system is doing something wrong.
Also, it illustrates a more general design philosophy with Airbus that has led to other incidents, which is to hide important information about what the automated system is doing from the pilots and limit their ability to interfere with its operation. The pilots have no direct readout of the AoA sensor values that the automated system is using, or indeed of most of its other inputs. It was also not clear to the pilots exactly what mode the automated system was in (they thought it was in Direct Law when it wasn't), and there was not a simple "stop the automation" button they could press to put the plane into a known manual mode with known behavior.
While I would agree that this is not the same specific failure mode as MCAS was with Boeing, I'm not sure it's not "remotely in the same ballpark" as far as long term implications are concerned.