• I’d be tempted to do what you say if I could get faster response time on whether or not to do something. Getting an answer once a week works acceptably (not great, acceptably) for features, but not for bugs.
• We suck at estimating how long it will take to fix a bug, so if we care about a level velocity, having both in the same bucket would hurt. Maybe we don’t care about having a level velocity, though.
• Bugs that are causing red bars are, to me, special: they’re actively interfering with our ability to write correct new code. Which doesn’t mean that they shouldn’t be put in the same backlog, it just means that it would be wise to put those bugs near the front.

I don’t really feel comfortable that what we’re doing now is particularly the right way to handle bugs. I do feel comfortable that the way to make things better is to fix lots of bugs (with the agreement of all parties, of course). Once almost all open bugs are things that have been broken for ages or never worked, and aren’t actively causing problems, matters will get a lot clearer.

I just hope it doesn’t take too long to get there…

Programmers have to do different things to fix bugs and implement features, but why should that matter to managers or customers?