Two questions I think are still unclear:
Through what pathway did the faulty AoA sensor feed bad data to the trim stabiliser?
People are discussing the STS as a possibility, but AoA is not a direct input to this system. Instead from the AD it seems that a single AoA failure can contaminate the CAS at the ADIRU and generate airspeed disagree even with no faults in the pitot/static system. Under this scenario the STS could continue to operate, trimming the stab down in response to faulty low CAS. However, it seems unlikely that this would present as stabiliser runaway to the stop, as even with faulty AoA data it shouldn't be able to revise CAS that much (CAS is primarily based on the presumably working pitot/static). If this was the case, this would be a known problem with NGs as well as MAX, with single AoA failures in the past would leading to similar problems (which doesn't seem to be the case). Which leads to:
Does the MAX use AoA data in any way differently to the NG?
If the use of AoA sensor data hasn't changed from the NG then this accident must truly be a black swan event, with some other secondary malfunction to the AoA fault interacting to give the trim runaway. This is a pretty terrible combination with the elevator feel system (which is directly acting on AoA data), a faulty high alpha value will trigger stall protection and make it much harder to pull against the faulty automatic down trim, probably with the extra burden of simultaneous stick shaker.
The confusing fact the AoA sensor failure seems to only announce itself by it's flow-on effects on other systems (IAS DISAGREE, FEEL DIFF PRESS) seemed to affect not only the crew but maintenance, who after replacing the AoA sensor and still getting problems (suggesting the AoA failure is not in the outer sensor module), returned to hopefully trying maintenance items on the ports and checking the connectors on the feel computer.