This post was triggered by blog post Resolved as Not Repro - http://thetesteye.com/blog/2009/06/resolved-as-not-repro/
I believe that bug systems too often are used with onlý a this-project-right-now approach, where you care most about just getting all items dealt with.
This is perfectly fine for one-off type of projects, but does not work fully for software where the bug system is (one of) the most important sources regarding quality information.

Since I use a holistic-subjective approach to testing, I need to consider both now-and-then, and also me-and-everyone-else.
Testers, developers et.al will treat bugs differently if they are resolved As Designed, or Fixed, or External, or Worksforme, or Not Repro, or Invalid, or Postponed, or Won’t Fix or Duplicate. 
At the end of this project, or next version, I might look again at all bugs set as Not Repro, or re-verify the most important Fixed bugs.
If there are many By Design issues, some usability folks might look into the details, and consider new approaches for the area.
Support people might search for information, and act differently depending on the solution of the related bug.
And also people that think that metrics matter, might be even more deceived, if the resolutions aren’t the correct ones.

My point is, you can’t really know how the information may be used, so do your best.

At www.context-driven-testing.com you can read “Metrics that are not valid are dangerous.”
I believe this is true, but I would rather prefer “Metrics are dangerous.”

Uninterpreted measurements are not bad by themselves, but when value is added to them, they become metrics, and dangerous because they state specific things without considering a lot of other things, that actually might be much more important.
If measurements are used together with knowledge of details, you might have an analysis that is fruitful.
But at many times, sound judgment not only is enough; it is better.

Measurements/Metrics are probably useful for dead things, like manufacturing objects, but m/m are not good for complex things involving people, e.g. software testing. Metrics uses numbers to reduce the complexity and thereby the “truth” disappears.