TIMTOWTDI Bugs

Over the past few months, I’ve stumbled across a baffling class of bug. Basically, the old saying “There Is More Than One Way To Do It,” where one way works correctly and another doesn’t.
Bug 267050 is one example. In that one, clicking a link works. Entering the link’s URL into the location bar and hitting enter results in a crash.
Another is bug 258365. In that one, replacing one node with another leads to a crash, but inserting the latter and removing the former separately works flawlessly.
In a sense, once a bug is recognized as a TIMTOWTDI bug, it’s both good and bad. Good in that the person who discovered the bug can always work around it, but bad in that the workaround suppresses a bug. For people who hack the lizard, good and bad here are reversed. Mozilla developers want to know about and to test bugs so bugs can be fixed, but if the user works around it, it just stagnates and bites probably another three or four people who haven’t reported it yet. So these kinds of bugs unintentionally and inadvertently pit developers against users, at least in the terms of what the goal is: to make things work right.
I don’t really know how to analyse TIMTOWTDI bugs. For all I know, there may be a better-known term for it.
The only idea I have towards supporting both the application developer and the Mozilla developer is for the application developer to include debug-only UI controls for changing execution paths on the fly within their own application.
I’d appreciate some feedback on this, including your experiences with this class of bugs, editorializing, suggestions on tracking such bugs down, etc.