How do you propose filtering tech support from bug reports at scale?
The trick is to set the quality threshold high. It should take a couple of hours to report a bug but that should be because of the effort of writing the issue - not because you navigate tech support phone people.
So basically "I can't do this thing I need to do, although it worked in the last version" is tech support - not a bug report. With the minimal steps to reproduce, some logs and perhaps a vm image - it's s bug report.
These customer support people talk to people like this all day. They can know when an issue is an actual bug.
Getting the bug report to the right dev and eliciting the ever-important "huh, that's weird" is a really tricky routing problem due to Microsoft (and similar companies') scale.
So... maybe... a team could be created, whose sole purpose is to distill potential issues into tiny testcases that take the fewest number of seconds for someone with domain knowledge to look at and go "okay I doubt this is invalid". Not to actually repro the issue (which might require significant setup), but rather to get an initial go/no-go.
Then teams around the company could be routed batches of testcases to look at every couple of days.
I know I'm describing issue tracking here - the specific point I'm getting at is that the first team I mentioned would handle all the back-and-forth with the customer until the testcase was as small as possible.
The caveat emptor with this idea is that it's inspired by a single datapoint (OP's bug report) and may not scale to more nuanced problems. Hardware failure, for example, would fall right through this approach.