Complexity and quantity of software testing and validation B may be required to undertake could still be significant?
Been following this topic since the start and while I'm not a professional pilot I did work a lot on Avionics software in the 80s, none of this was flight critical but I did work a lot in fuel gauging, writing real-time software both in assembler and Coral 66 for 6502, 8031 and early versions of the 286 processors.
The most recent articles seem to suggest that alongside the MCAS SW changes B has moved (or been forced to move) the flight management computer from a simple dual-redundant system with a clear master-slave (active-passive) split between each "side" of the pair. To a semi "active-active" system where both sides are constantly checking each other and exchanging data/taking duplicate data feeds in real-time. If this is the case they will have a "shed load" of retesting to do. We did a similar thing way back when we modified a successful (and quite simple) fuel gauging platform used on a number of civil and military aircraft from active-passive to semi-active-active for a new airframe. We were finding race conditions, putting in semaphores and re-writing working code for nearly a year before the system was fit for purpose. There was little/no change to the functionality of the fuel-gauging S/W just the change of operations with respect to fail-over and real-time checking. Major project.
Typically each hour of software changes require at least 10 hours of testing in rigs before anything was near being suitable for flight testing.
We weren't flight-critical so we could fail hard and reboot it if things got messy. I would guess B don't have that option so god only knows how they are planning to deal with disagreement between each side of the system during normal operations, dual systems can't do majority voting :-). As a result, I would expect a number of new issues to be found in the system for some time after it has come back into service.
With respect to the comments on 286 I would guess these are all mil-spec components and will be around for many, many years (you can still get brand new mil-spec 8051s and I was working on those in 1985!). Flinging more modern CPUs at the problem is not likely to be a sensible approach and would require significantly more work to recertify?
I know the current issue is B specific but I also think that the "grandparent" rules aviation has been using for certifying new versions of older airframes will need some looking at in light of the Max issues?