if789:
Originally Posted by
MurphyWasRight 
A much simpler and reliable solution is to latch the stall warning once a (fully developed?) stall is detected then do not clear the condition until sensors show the aircraft to be flying (unstalled) again.
While clearly not the "cause" of this accident the stall warning re-appearing when the correct (ND) input was applied could not have helped.
Define "sensors show the aircraft to be flying (unstalled) again" in the case where those sensor values are out of valid range. That is where the complex software comes back in with all the associated problems / risks.
If the sensors are out of valid range, for example airspeed <60kts, then the aircraft is not in a normal flying range and since it was last known to be stalled it most likely still is.
No need for fancy checks. the currently inhibited (likely to reduce spurious alarms on landing etc) "stall states" such as air speed <60kts would not be able clear the warning.
Importantly they would continue to inhibit -entering- the stall warning state.
As to spurious warnings due to (undetected) sensor failure the current logic would likely continue the stall warning if the sensor failed in a way to inidicate a stall so things would be no worse than they are now.
Mainly just pointing out that considering a bit of recent state history can allow for a more robust desging compared to trying to determine current state from a single snapshot of data.