But you see, I do software dev too, and you accept ALL bugs that can be reproduced/IDed. You also plan to address ALL bugs. It's not a matter of fixing the show stoppers, getting RTW out, and maybe fix some more later. You fix them ALL, you have a timeline and a plan. If you address bugs some other way, there might be a problem with your methodology. In the last few months, we've seen a number of rather large, economy-breaking bugs, and the FDev "response" has been to disable the relevant sections of the game. These weren't deep bugs intrinsic to the game design, engine, etc. In the case of passenger missions, or this one, it would be fairly simple to make some basic catch statements to prevent/constrain this.
Granted, and I agree - they all need to be fixed; but when you work on a schedule and don't want to keep pushing things out; you have to make sacrifices. No dev likes to have bugs in his product; but you can't fix everything right away. I hate releasing code I know has bugs in it; but most times I don't have the luxury to get them fixed. I look at them after we release something and begin our next sprint planning session.
Time constraints, other work, release schedules, managers who think bug-ridden software is acceptable for release and so on all play a part.