The problem isn't with your bug-tracking tool chain. The underlying problem is a lack of rigor in defining bugs in your business context, and possibly a lack of clarity in the business objectives that your organization is trying to achieve.
The solution is to define your terms unambiguously, clarify your objectives, and then build processes (including bug tracking and change management) around those objectives in a sustainable way for your particular business.
What Bugs Are Not
Your question mashes a bunch of things together. You said that it is difficult to:
- Estimate implications of each bug (including risk, technical complexity, etc.)
- See the whole picture : How stable is the product? Did the quality drop with the last release? etc.
- Identify duplicate bugs
You're confusing bugs with product stability, business risk, and work effort. While all of these things may be associated with a bug, they aren't synonyms. So, let's start with a workable definition.
Defining a Bug
Here's my personal definition of what a bug is:
A bug is an aspect of a system that performs improperly (e.g.
2 + 2 = 5) or fails to meet requirements or customer expectations (e.g. the specification is for 10ms response times, but printing "Hello, world!" takes 17.5 minutes).
Your project may have a different definition. That's fine; the important thing is for everyone to agree on what it means when you call something a bug.
Bugs Need a Point of View
A bug needs a point of view. Generally, a bug that impacts no one isn't a problem, so it's important that a bug have a context and a point of view. A bug that electrocutes end-users is probably a business-critical bug that needs to be fixed right away, while bugs that are not customer-facing will probably have a different priority for the business.
If you don't understand who the bug impacts or why it matters to them, then you can't identify business risks or quantify the value of fixing (or not fixing) a particular bug.
Customers and Managers Don't Get to Estimate Complexity
While it may be legitimate to allow the bug reporter to provide information on the severity of the bug's impact on a given person or process, that's not the same thing as estimating business risk or work effort. The best way to make sure you estimate something poorly is to have the wrong people provide the estimates. As a result, initial bug reports shouldn't contain estimates of risk or complexity; it's the team's job to evaluate those issues.
In Scrum, the Product Owner should determine what the business risk and criticality is of the bug. She may or may not consult with the rest of the team if the risks are wide-reaching or non-obvious, but ultimately prioritizing things is her job.
Likewise, only the development team gets to estimate the complexity of the bug. After all, they wrote the software--and presumably the unit tests that can at least reproduce this bug--so they are the best people to estimate how difficult and/or invasive a given change is likely to be.
Don't Ignore Duplicate Bugs
Cross-referencing bugs is fine. However, automatically de-duplicating bugs is almost impossible. Either you end up with a bug reporting system that's so limited that only pre-defined bugs can be entered, or the free-form nature of the reports makes finding exact duplicates impossible.
Every bug needs some human triage. If bugs are related, it's okay to mark them as similar or exact duplicates of some other bug, but the fact that you have 973 "duplicate" bugs about your Super-Duper Widget is probably a useful metric in its own right. Why would you want to discard such valuable data?
Bugs are Not Intrinsically Code-Quality Metrics
A bug report does not intrinsically tell you anything about either code quality or product stability. A code base riddled with easily-preventable bugs is obviously a red flag for your process, as is a high volume of bugs that crash the application or its host system.
However, some bugs are just a result of emergent system behavior, changes in user expectations, poorly-chosen metaphors and paradigms, or simply unforeseen circumstances. These things are definitely bugs, but they don't mean your code base is bad, your programmers are lazy, or that your customers are idiots. They are, at heart, just specifications for change requirements or new user stories.
If you want to measure code quality, there are other ways to do that. However, I'd argue that end-user satisfaction and code base sustainability are the metrics that matter most. Measure those two things properly, and life will be easier for everyone.