Unfortunately, this sort of testing falls short when you start adding asynchronous events into the middle of your program flow. Preemptive operating systems are becoming increasingly common in automotive. With a fully preemptive system, it is impossible to test every possible stackup of task preemption on the bench and time prohibitive to do it in simulation. Concurrency issues are mainly avoided through proper design and implementation practices of both the operating system and the application itself.
When concurrency issues appear in the field or on the bench, you have the same scenario as Toyota... The knowledge of "It did this thing this time" and unless your testing generates the exact sequence of events to microsecond precision, you may never see the problem again...
The biggest issue I see is that there is not a single party to blame for many bugs. Who is most to blame? The developer who made the mistake in the first place? The person who wrote the test plan that didn't cover the scenario in which the bug appears? The person who signed off functional testing? The person who signed off on the code review?
Quality processes are put in place to protect the company from the inevitable mistakes of a single developer. If the company has a proper process in place, it becomes extremely difficult to point the blame at any single person. And if the company can't be bothered to put a proper quality process in place, management is just as much to blame for errors in the end product as the developers themselves.
"This isn't brain surgery; it's just television." - David Letterman