It's a bug if the end users have a problem with its "design".
That is a "training issue".
Where I last worked, we called them "problem reports" and did not differentiate bugs from requests for enhancement. The were filtered by the end user representatives and CSRs first. If the PRs were forwarded by them, we (in software development) worked on them.
Where I work we have problem reports and change requests. It is sometimes difficult to get end users to know the difference.
If something is not working the way it once did or the way we (who know how it should work) say that it should work that is a problem report. In a DISH related example, this would be someone saying "my receiver does not exit the screen saver when I press the power button or press select". The receiver is supposed to exit the screen saver - it is not doing what it is supposed to do.
If a user wants something to work differently that is a change request. In a DISH related example, this would be someone saying "my receiver does not exit the screen saver when I press the 7 button or any other number key on the remote". While it would not be wrong to have a "wake on any key press" feature (other than accidental waking) not waking on "7" isn't an example of something that is broken.
Problems are usually solved, requests may not be satisfied. That is the primary difference.
There is certainly a greater importance (in both my and DISH's worlds) on resolving problem reports - bugs - before going after feature requests. Would you rather have DISH work on a problem such as "receiver shuts down every 30 minutes without warning" or a request such as "add Hulu app"?
Allowing other codes for IR remote control is a good feature request. Since that feature was not on the 922 I would not promise that feature would ever be added (and even if it was on the 922, features can vary). Allowing TV2 on older receivers to be controlled via IR (for Slingbox use) was a feature that sat in the "please add" queue for years. That too was a good feature request.