> I don't want to take this off on a tangent, but this theory of the AF 447 crash keeps getting repeated online despite the fact that the accident report did not conclude that the UI was a factor.
This is incorrect. The BEA report explicitly blames the lack of an AoA display and recommends that an AoA indicator be directly visible to the pilots. The aircraft already has sensors to measure AoA to feed the flight computers; asking for a direct readout of AoA is nothing beyond a UI change recommendation (and not fundamental aircraft re-engineering):
> It is essential in order to ensure flight safety to reduce the angle of attack when a stall is imminent. Only a direct readout of the angle of attack could enable crews to rapidly identify the aerodynamic situation of the aeroplane and take the actions that may be required.
The AoA invalidation logic ("mark AoA measurements as invalid if airspeed is less than 60kt") made the stall warning turn off as the stall became even deeper, making diagnosis of the stall more complicated. Worse, the BEA report states that the appropriate (nose down) control input led to the stall warning reactivating (since such an input would increase airspeed above the 60kt threshold -- inherent to a proper stall recovery), leading the pilot flying to reverse their control inputs and return the aircraft into a worse stall:
> A few seconds after the transition to alternate law, the stall warning sounded briefly, even though the PF’s inputs should have made this warning sound for several seconds. The reason for this is the drop in the measured airspeeds, some of which fell temporarily to below 60 kt, while the angle of attack reached 40°. Furthermore, the drop in measured airspeeds to values of less than 60 kt during the stall caused the repeated activation and deactivation of the warning which may have made it considerably more difficult for the Captain to effectively analyse the situation on his return to the cockpit.
> Several nose-down inputs caused a drop in the pitch attitude and the angle of attack, whose values then became valid, such that a clear nose-down input resulted in the triggering of the stall warning. It appears that the PF reacted, on at least two occasions, with a nose-up input, whose consequences were an increase in angle of attack, a drop in measured speed and consequently stopping the stall warning.
Lacking an AoA readout, the pilots would have had to reverse-engineer AoA from their extant instrument displays, the warnings they were presented, the "feel" of the airplane (is it buffeting? how is it responding to various control inputs?, etc), and past control inputs. Every one of those sources were degraded per the BEA report: they didn't trust (to the point of changing the selected inertial data source even if there was no indicated issue with inertial data) their instruments because of the airspeed inconsistency, the stall warning would reactivate every time they made the correct control input (the exact opposite behaviour of a stall warning simply based on an AoA threshold), and buffet might have been interpreted as overspeed buffet.
Expecting pilots to reverse-engineer the aircraft's warnings to guesstimate AoA -- a value that the machinery simultaneously measures and hides from the pilots -- is fatally bad UI (BEA uses the fancier term "ergonomics"), especially in cases when the flight computers deal with air data inconsistencies by forking over more authority to the pilots.