On the ”we should be worried” end of the scale, we have
”we fixed a bug but didn’t add a test, then accidentally reverted the bug fix, had to fix it again, and still didn’t improve our process to prevent this from happening again”
In the exaggerated version, they don’t use source control, so they had to figure out how to fix the bug twice, and they don’t even did a test, but, in both cases, only believed they fixed it.
Going back to your example, it depends on how they detected that they missed cases, and on how sure they are they know them all now. If (100% hypothetically) they only detected it after ten people died, denied existence of the problem, and were sued in court, we should be worried.
In the real world, just like all other companies working on autonomous driving, I think they will never be able to say they truly fixed the problem. The problem is, and always will be, underspecified, and even if we knew the problem well, we don’t really know for what kinds of problems the software we use to do this is a reliable solution.
I would be a bit more worried about Tesla than, say, about German car manufacturers because Tesla has shown to be willing to sail close to cliffs. Worried enough to be really worried? No.
It's entirely logical.
Zero patches, one, two, or more. That there are patches merely tells you that they tried to respond to an identified threat. It doesn’t tell you the threat was properly mitigated in any case.
I think we can say it is strictly better to have more than zero patches in the case where a vulnerability is public. Exactly one patch to me doesn’t guarantee anything about the quality. Multiple patches at least implies persistent effort and dedication to securing the fix. Maybe at some point the number of patches implies incompetence but I’m not sure I’d draw that line at “2”?
Now, in the case of an undisclosed voluntarily, waiting may be preferred as a path is going to get people to look on that direction. However, with public disclosure the clock is ticking.