Because when you go in the issues tab, you then choose to only see "bugs", which will show you the one that needs handling, and you can ignore the 999 others.
But no, the wording isn't the only/main issue IMO, it's the lack of a clean separation between problems which should be fixed and non-problems which don't need to ever be resolved. It's a cognitive thing for maintainers, I believe mixing up those things contribute to burn-out through the purely psychological effects of being told by the UI that there are 100 things which need to be solved when there may in fact only be 5, it's a public perception thing when the stat that's prominently placed on the repo page is the number of open issues.
And yes, it's vague. It's not the technical lack of a good enough labelling and search system. And maybe different people react differently to this stuff, maybe some people have no trouble dealing with the lack of a clean separation. But given the fact that burn-out in open source is such a huge issue, maybe conflating the stuff which must be fixed and the stuff which doesn't have to be fixed isn't such a great idea.
If all you are saying is that it is a UI issue to mix those two categories when you open the issues page for the first time, it is pretty easy to bookmark or link to a list of issues filtered by label.
If that doesn't relate to what you are saying in anyway... then I am really unclear on what you are trying to say