So, I think about these sorts of things for a living. My full-time
job is helping people configure and customize their Bugzilla. I'll say
that I've spent no small time thinking about Bugzilla usage in the
last many years that I have been working on Bugzilla.

  The workflow that mconnor has proposed here is probably the best
simple workflow that there could be, although some projects may also
want a VERIFIED state (though I can tell you that at least for the
Bugzilla product, it adds little value). However, I would change NEW
to CONFIRMED, for clarity's sake.

  When designing a status workflow, there are two questions to ask: 1)
What is the actual process a bug goes through. 2) What key information
does the status field tell us about that process that other fields
don't already tell us?

  Example of a useless status: The old definition of ASSIGNED ("I
accept that I am assigned this bug") is useless because the Assignee
field already tells us that.

  Useful status: INPROGRESS--it tells us something that no other field
tells us--that the person is actually working on the bug right now, or
that work has begun.

  The actual process a bug goes through varies depending on the bug.
Let's say that it's a defect in a large project like Core or Firefox.
Although I haven't done triage for those products in many years, I
would imagine the process is still somewhat similar:

  1) A bug is filed. If it is filed by a developer or a trusted QA
technician, it is automagically CONFIRMED, otherwise it is
UNCONFIRMED.
  2) Somebody confirms the bug if it is UNCONFIRMED, or closes the
bug.
  3) Now that we know it's a bug, somebody has to decide (a) what the
priority of the bug fix should be and (b) who should be fixing it.
Depending on the organization and the product, these happen in
different orders, or sometimes simultaneously. Sometimes the assignee
does the prioritization. This all doesn't matter, because the Priority
and the Assignee field cover this stage, and we don't need a status
for it.
  4) Somebody works on the bug. Currently there is no field that tells
us it's being worked on. In the Bugzilla product, we use the ASSIGNED
state for this. (If you do make an INPROGRESS state, please just
rename ASSIGNED, don't delete ASSIGNED. People can reset their bugs to
NEW if they are not actually INPROGRESS.)
  5) A patch is posted. We know this because well...a patch is posted.
  6) We go through the review process. We know this is happening
because of flags.
  7) The patch is committed. We have a status for this: RESOLVED
FIXED.

  That comprises the entire actual significant engineering process for
fixing any bug in any product, really. Depending on how much
procrastination you want to go through or how massively many bugs you
have, you could also have a CAUSEKNOWN status, where we know what the
bug is but haven't fixed it yet. I think it requires a tremendous
number of engineers and a tremendous number of bugs for such a status
to actually become useful, and I'd tend to think that it would be
either so transient as to be useless (as bugs are almost always
patched shortly after the cause is known) or merely a method of
procrastination ("Well, I've found the cause, now I should move the
status and go on to something else, since the existence of this status
validates the fact that merely finding a cause is a significant-enough
amount of work to do on a bug").

  By the way, "NEW" is a useless status as well, I think--we can tell
that a bug is new by the date it was reported, the lack of comments,
and the lack of changes to it. That's how I actually tell that bugs
are new.