Let’s assume the following situation: in the past a feature was implemented, a full DoD (code review, manual test, stakeholder approval, ..) was done and the ticket successfully closed.
Suddenly someone realizes that a second feature, which is closely related to the first one, should have that behaviour as well. The circle of people cavilling about the lack of functionality is identical with the people writing the requirements and doing the validation of the implementation of feature one.
So, is this a bug?
No, this is a new task!
It is devaluating the efforts of all people involved in first place, because the work was delivered like ordered. Nobody complained – until now.
Let me explain, because this sounds like nitpicking and fussing about the wording. But the inner problem is, when stakeholder and requirement engineers couldn’t capture all use-cases or had implicit, inner expectations and did not note them down before (or while) development, then you can’t suddenly name the lack of some additonal change a bug.
Or you can. If you want to piss of your developers :>
Another aspect: at the end of sprints or releases reviews are done. And at this very moment only numbers matter. You won’t dive into the details of each tickets – so only the binning of the types of solved issues matter. And mislabelling the aforementioned tasks as bugs can make a good-team result appear like a “barely made it over the finishing line”.