The question might not be as simple as it sounds, as we have struggled with this a bit. If there are 5 separate bugs, which can be taken care of with a single fix, then it is wasteful to take this approach. One bug might slip through the cracks, and would take away from a complete picture, or just be hidden for some time (we have several years worth of outstanding bugs, and our bug tracker sucks at searching :( ).
Now, if you file a bug of 100+ parts (such as help tooltips are missing from all 234 dialogs), then it should be treated as a project and be broken down. However, if it is a bug of 3-4 parts, then the developer would attempt to fix all 3 or 4 at once. This is where it gets interesting. What if the coder only fixes 3 or 3.5 out of 4? Should after testing a new bug be filed and old one closed? If yes, then this invites sloppy programming practices, where close enough is good enough. If the bug is to fail, then all of it has to be re-done and re-tested. Now ... what if part 1 is the size of a breadbox in terms of size and risk, part 2 is more like a car, part 3 is like a house, and so on :)
When sizing and prioritizing this bug (I must mention that we use Scrum), the house part was not noticed - who reads anything but a bug title anyway? So, it was deemed a low hanging fruit - low effort, low risk, happy user = high reward. But, we got bitten with one of them recently. What seemed to be logically the same area, was actually code in transitional state, where we are trying to deprecate one method of doing things, or one library for creating widgets with another, new and better. The problem is that we had to release mid-conversion, so we made two very different beasts look alike. Our QA folks did not know that, are not expected to know that, and so in their mind these are all the same issues.
We need to be QA-friendly - not to push back too hard or too often, but also try to give a set of heuristics which would help to decide whether to file one bug or many. I suppose the problem might lie with weak tools, where splitting and merging bugs is hard to do. However, how do you deal with this stuff in general?
P.S. In Scrum - once you committed to fixing something, it probably should be fixed. Break this rule too many times and discipline will degrade.