There are a lot of confident and ridiculously detailed statements about the softare use din MCAS even the language used to code it. None of thsi is relevant. It is clear that the root is a system design error compounded by a failure of hazard and failure analysis and the regulatory/certification process.
I can see quick fixes which address the deficiencies in the way MCAS responds to erroneous inputs which from a functional point of view make the behaviour safe. I can't see a quick fix which address the wider hazard/failure analysis and regulatory concerns.
I write safety related software but discussing which language or tools to use to develop SW when the fundamental concept is flawed make no sense. The best solution to a safety hazard is intrinsic - remove the hazard, in this case that means aerodynamic changes and I assume that won't happen but it should have been thought about at the design stage. If intrinisc safety is not possible then a functional safety like MCAS is possible but the consequences of failures must be considered and controlled and any additional hazards by introducing the functional safety sub-system must be considered. I assume this was done, at least in the formal sense but it seems to have been done inexplicably poorly. This was not a case of a complicated combination of unlikely events but an entirely forseeable concsequence of a single failure. IF MCAS is retained it has to be designed and developed appropriately given the impact of it failing and that is not going to happen very quickly.
Ther eis no evidence I am aware of that the software did anything other than what it was intended and specified to do. Even the software specification was not really the eproblem. The problem was the overall system design and the safety analysis behind it. It is actually quite shocking and shoud result in a very deep analysis of both the development and regulatory processes.