Is this Arantor from SMF?
My reputation sadly precedes me. (I'm also Pete from TAZ, but that's also another story.) Also this is my entire professional life - I have similar issues with various of my customers reporting things that usually end up with me sending back requests for further info, or even getting on a call with them to show me.
At heart we're talking about a communication problem represented by 'what is obvious to the person is not obvious to me because they haven't used their words to convey all their thoughts'. So, we must figure out how to make it easier for them to tell us things we need to know, and how to avoid everyone involved being lead astray.
Step 1: get rid of historical support topics. Chances are support issues from 3 major versions (might as well call them that) and 15 years ago almost certainly are not relevant, and are at best a distraction. (If they are still relevant, you have screwed up, and you deserve everything you get.)
Step 2: make it as easy as possible for the software to help. Every error message should have a number or code or something that can be looked up in a reference guide. As a general rule, provide as much meaningful, specific data to the person with an issue as is achievable in the situation. The more specific, the better. Bonus points if every error has a guide on a wiki or similar where people can do a search and find the normal next steps. Even if those steps are diagnostic only. Make as it easy as possible for someone to get you enough to act on without you having to ask.
Step 3: Need better interconnect between wherever the people are going to ask, and wherever the answers probably are. I don't mean 'find similar topics based on subject' because that's just nonsense for this. I mean, be able to interrogate wikis from the support forum, especially matching on error codes. I could go on at great length about the failures of modern community platforms and their inherent siloing of content but I'll be saying enough here, so let's not just yet.
Step 4: Have a set of well-written FAQs. Your support folks should be able to tell you what the common support questions are. Having a way to point people at the (right) FAQs is good. Make this obviously discoverable. Again, the angle is to make it as easy as possible for people to find their own solutions, ideally without having to ask. This is mostly for cases where the issue is a 'how do I do x' challenge rather than a 'something is broken' challenge, but they're both support issues.
Now, you're never going to fix this problem. It's not fixable, sometimes things just break and that sucks and you need someone to come in and fix it but you want to make it as easy as possible for them to do so - so have the platform be able to tell you what's wrong as best possible. Build diagnostic tools if that makes sense. Make it possible for people to run these self-diagnostic tools and give you the results. Anything you can do to make it easier for people to help you pays off - because what you'll find is that the people who can't even get *there* will be helped along by the people who are a set further up the chain without dragging the actual support folks in.
Step 4a: don't have templated support tickets. Nor custom fields pushing users for a version number or stuff like that. People don't like it, they get confused, and they'll put in whatever answer gets them through the form quickest, more than they'll put the right answer. It's not unheard of for people to post in the wrong board because they just hit the first one under the support heading, which if that is your oldest version... oops.
And you're always going to have people who aren't interested in doing any of the work themselves. And that's sadly inevitable, but it's life - the best you can do is try to meet them half way. Make it as easy as possible for them to get the information to you.
Big chunky naming schemes are good for this, people actually tend to remember the name of a thing more than a random version number, and are less likely to get it weirdly wrong - SMF currently sees people mangling 2.1.3 into 2.0.13 and similar which can be annoyingly confusing. But if you decide that 2.1 is 'Melon', you can make it 'Melon-3' for third patch. It can even internally *be* 2.1.3 but giving it a name works. Same way that Android and Ubuntu do this - yes, there are people who will latch onto the version number, but these people tend to get it *right* when they do. Give everyone else a chunky name they can latch onto. Makes it easier for everyone.
Stretch goal: when you have common reports of an issue causing support - it doesn't even have to be a bug - FIX IT. There are times that 'this is not how it was designed' is an appropriate response, because sometimes what the user wants to do is a) a fundamentally, objectively bad idea and b) so counter to the implementation that you're not going to be able to hammer it through.
But if you keep seeing the same sorts of requests, that's not the time to sit and defend your design unless you want to say 'we're not going to fix it, sorry, we didn't anticipate this'. And, in some cases, that *can* be the correct answer. Turning a forum into a chatroom is the sort of thing - both forums and chats have a place, and even some interconnect can be good but not a fundamental repositioning of one to the other in some unholy reverse-Discord. But some of the time you do need to identify that actually, the design was bad and FIX IT.
A support request is, by definition, a failure of the project. It is a failure to communicate how to solve a specific problem. Or it is a failure of the development to spot a flaw. Or it is a failure of unanticipated (or anticipated but overruled) need. This is not to suggest that all failures are equal, or that all failures are *bad*, because they're not. Some of these 'failure states' are unreasonable expectations but nevertheless, they are representative of 'the user tried to do something they expected to do, or reasonably be able to do but could not do, or could not work out how to do'. This does not even mean that the software failed in itself, but that the project has somewhere - in theory any suitably functioning ecosystem would yield most common requests either directly in the core product or in some after-market in the form of add-ons/mods/whatever you call them. Any such failure here is either the product of 'the ecosystem failed to deliver' or very commonly 'the ecosystem failed to communicate that a solution existed'.
There are further things that could be applied; but that feels far too far down the ITIL and ITSM playbooks for my liking. Communities don't need regimen, they just need to make it as easy as possible for everyone involved to do the right thing.
