WE obviously do not read the same posts in the same way. I haven't seen on this thread a single Airbus pilot who's said that it shouldn't happen to him, or have they showed a blind trust to the system.
Of course, we all have your preoccupations.
edit: 
your preoccupations? It should have been
our!!!! Sorry, Lemurian, that was unintended
[/i]
This said, why don't we bury the War Axe ?
Thank you. Really. Running an axe is the last thing I want to do here.
...good account of most of the accident facts and events we have...
This was as far as I can tell a pretty good explanation of the steps that led up to the accident, and I really thank you for it's factuality. I know I've lost that to some polemic tone at times, but that was out of frustration about the obvious communication issues here.
Now, you have to understand that we're coming from different angles. You're obviously the type of person who has flown a lot of different airplanes and learned to adapt to the requirements and procedures of all of them and you're comfortable with that.
I'm just a humble sparetime-pilot with an interest in aviation as such.
But I've also spent a considerable amount of my professional time designing and working with logic systems, both hardware and software.
You know that you can paint yourself into a corner as a pilot, but I'm equally aware of the fact that you can paint yourself and your users into a corner when you're designing logic. I've also learned a bit or two about how humans interact and that this is not always unambiguous. Actually ambiguity is the norm in human interaction with anything. (just look at how different we perceive the very same words in this thread).
In your post, you've described yourself how vision as a sensory input channel can and will become very focussed on one thing when we're under severe stress. The auditory channel can even get completely lost, especially when there's multiple auditory stimuli competing with your attention.
This is exactly why I suggest that there is value in things that actually move in the cockpit as the underlying system changes important parameters such as thrust and spoilers. If you have your hands on the throttles and they move back, that's some very direct input.
From my experience with state machines, I look at the state machine for the spoilers and subsequently the autobrakes and I go wow, that's an awful lot of parameters required to be TRUE in the boolean sense. I'm sure you remember the Warsaw accident where one of the parameters, the right squat switch, was almost true, but not boolean TRUE.
This is the point where I wonder what a tie breaker for this state could improve and what potential dangers it could bring with it.
The first memory item on "no decel" is "BRAKE PEDALS - PRESS", right?
To me, it would make sense to feed that into the state transition as well and define it as an override for the rest of the conditions. If we have maybe 90+% max brake pressure on the pedals, isn't that a clear indication that the pilot has committed to the landing and wants to get to a stop? Of course, there needs to be a minimal lockout against doing that in flight (maybe wheel spin up or squat, but minimal, one would be sufficient).
Would that have saved the day? I don't know.
I just know that the system as it stood on that day had no way of forgiving the original error.
In the Warsaw event, Airbus did indeed change the logic afterwards. Logic is only ever as good as what the designers have envisioned. The fact that one thrust lever could be completely forgotten about was either not on their list at all or it seemed so ridiculously improbable that they did deliberately leave it out of the equation.
Today, however, we know that it has happened, and happened more than once.
To
prevent error means to create interfaces and structures that are easy to understand, straightforward to communicate with and unambiguous in their feedback.
To
forgive error means to try to design logic that does not carry forward errors or, if it has to, allows to transition to an error free state without having to analyze and correct the original error in a stressful situation.
To
fail gracefully is probably the most difficult thing to design. The first two all deal with known or envisionable error, this one is about new and creative ways to err. This requires solid and correct situational defaulting. Let's say in this case, a logic could have looked at the given pilot inputs for brakes, thrust, spoilers etc etc and make a "last minute guess" of what might be the safest option. I know there's risk in here and I said earlier that I would not want to go down this road with the amount of knowledge I have about flying big iron.
So again, thanks for that last post, Lemurian, I don't think we're so far away from each other, we just come from completely different angles.
pj