"You don't support printing", "pressing the print button doesn't print", "pressing the print button crashes the computer" and "pressing the print button lets an attacker get root access to the system" are all different and it makes sense to distinguish them. (The first is a missing feature, the second and third are different kinds of bugs, the last is a special kind of bug we call a security vulnerability.)

That distinction might not be useful to end-users, but it's useful for the people building the system! If you want to care about quality, committing to a strategy like "we will not add features before we fix known bugs" is totally clear, reasonable and effective. There might be some frontier of issues where it's hard to make a distinction, but that just means there are subtle edge-cases, not that the whole concept is undefined. A lot of perfectly cromulent concepts have edge-cases! You can just decide those on a case-by-case basis; if it's actually so close as to be legitimately confusing—it's not just feigned ignorance or political posturing—which side you choose probably doesn't have much of an effect.

This does depend on having a reasonably clear idea of what you're building, but that "reasonably clear idea" does not have to be anywhere near the detail of a "full spec", much less anything formalized. To me, that seems like a baseline you'd need to build quality software at all, and hardly an unreasonable thing to expect. And if most teams can't manage, well, it's just another explanation for why most software is crap.

Any software has a spec. It might not be publicly written, but you have in mind what you build and which features it supports. And software that's sold has lists of features, presentation pages, and trials for people to see its features.

If some random user can't tell a bug from a feature, that's on them.

As a sidenote, I dislike it when a vendor makes me care whether something is a bug report, feature request, or support query prior to filing it. I'm willing to make an assessment on whether the query is of a public or private (if I'm unwilling to publish publicly, sensitive customer info, potential for vuln et c.) nature but beyond that I don't want to spend any time arguing about classification.