Indeed.
The nastiest ones are the ones introduced by compiler optimizations.
These are admittedly very rare these days; however, when they turn up "frustrating" barely begins to scratch the surface of how bastardly they can be to squash.
I somehow doubt that the beekeeper bug I mentioned is a compiler optimization based bug; it shows all the signs of just being rushed logic strung together on object types that previously had never even been contemplated as being usable for reactions. (Specifically, wild hives.) As such, establishing proper task locking and tracking would have required adding a whole lot of support code to elevate the randomly spawned hive objects into taskable objects that can be properly tracked and locked for task completion checking. --code that was either not completed, does not function the way it is intended, or was never implemented. (#TODO: Write object locking code here!)
It's entirely possible that toady simply didn't think that locking would be so noticably necessary as well, and may have been thinking in a "1 beekeeper, takes nearest hive, no problems!" Train of thought. I'm not clairvoyant, so I just don't know. If he has comments in his source code about that, I could never know unless he says something, because the compiler strips that stuff out when the executable gets built, and the best I would have would be a disassembly of the executable portion of the stack. So, it beats the hell out of me, and there is no way I COULD know unless he says something about it. For all I know, there could be dozens of lines of object locking code with comment headers in front of it in toady's source folder.
The point was that this is a known bug, the cause of the bug is known, the mechanics of the bug are well understood, the cause of the bug is well documented, the bug is "famous", and friendly suggestions on how to resolve the bug in a clean fashion are in Mantis already.
It has been 2 releases since the bug was introduced; no love for that bug.
Fixing the bug would make a very large number of users very very happy, and may well be one that a bounty could be attached to. There are other bugs that are equally famous, and vexing.
Trying to say that these are the result of "placeholder" bandaid code can get pretty tortured in some of the circumstances involved. I could sorta see that being the case with tracking wild beehives; toady may well want to roll tracking wild random features like that in with tracking wild features in his expanded elven site code, for instance, to have a more comprehensive framework, but if that's the case, he could save a good deal of kvetching from the player base and bug reporting members of the community by putting a single one-liner to that effect in the bug report, and changing the status from open to pending.
I hate to harp on this one bloody-nosed example, but it pretty cleary sums up a good deal of the frustration that bug reporters have when they report bugs, steps to reproduce the bugs, code analysis of the bugs, and steps to mitigate the effects of bugs--- in the bug tracking system, then basically get a cold shoulder after the bug is accepted as being real.
*shrug*
Rather than a "bug hunt drive", I'd rather see an incentives feature added to mantis, where people can donate a paypal payment, payable upon bug squashing, and add that to bugs they particularly despise.
The money can just sit there until toady gets around to it, and if toady finds he needs money in a hurry (he DOES live in the real world like the rest of us after all), it gives him a place to turn. It wouldn't be a replacement for general donations, but I think it would help incentivise the bug squashing situation a little without being offensive, like a kickstarter would.
The only issue is that toady has openly stated, REPEATEDLY, that money is not what motivates him. As such, I think that there should be a limit on the payout size on any such system, and that toady should get to impose/control those limits.
Eg, "famous bug X is caused by obvious defect, resulting from more hidden but much more difficult and less well known bug Y, and payout for X being greater than payout for Y is illogical." Situation exists, So, Today limits max contributor amount for X, puts a "bug related to bug #XXXXX" link in bold, and sets an appropriate value for fixing Y there.
It wouldn't be because toady thinks fixing Y demands that size payment, it's just a mechanism to prevent highly noticable bugs that would just go away after fixing far more pernicious and less well known ones from having huge payouts, while the latter, being much more work, gets no love at all from the community. If anything, I would endorse that kind of thing just for the added transparency in development it offers. It would give a direct value asseement into the work needed to properly address an arbitrary issue in the bug tracker.
And it would be a quick and easy means for toady to get some pocket money every once in a while, should a need arise.
I'm not advocating bribery or extortion here, just a means for value to be conveyed in both directions.
I'd gladly chip 10$ toward the beekeeper bug myself, for instance. I'd greatly like to know if the reason why its gone unaddressed is because of a pending feature enhancing rewrite, or just because it has low priority in toady's mind. As of right now, I don't know either way, and that's kinda demotivating. (Since I helped with the initial bug report on that one personally, and dug into the causes and steps to reproduce portion of the report, as well as instructions on how to mitigate in gameplay.-- I have a personal interest in why it isn't fixed.) It makes me less willing to file additional reports, and to me, that's a bad thing.