This reminds me of the following all-to-common StackOverflow interaction:
dev: <tries to figure out how to do abc. Due to various limitations, dev comes to the conclusion that the best way to do abc is using def. Explaining everything involved in abc is a lot of work, and dev just wants to ask about def> How can I do def?
stackoverflow: Don't do def, it's bad. Have you considered xyz?
dev: xyz isn't what I want. I really just want to do def.
stackoverflow: Don't do def, do lmnop.
dev: lmnop won't solve my problem. I just want to do def.
Yes, however there are times when you are enough of an expert in the domain to know why Y is the solution you need and you just want someone to help you with that part. You might know X better than anyone else, and explaining X won't get you far. You just want help with Y.
It is also true that there are many people who ask for help with Y and are wrong in thinking it is the correct way to solve X. I am describing the former situation and not the latter.
You need to reach the point where you have the appropriately shared context with the other person so that you are both able to work in the same direction.
That often involves explaining the situation sufficiently so that it is clear that the thing you are looking for doing it in such a way is the way that it needs to be done.
The vast majority of the time, when such questions are posted they are in the form of a work order and people who have gone through "maybe I should do XY" in the past have encountered some problems and are trying to warn you off of that path for the incomplete context that has been provided.
In such cases, it is necessary for the person with the question to sufficiently explain the problem, the context, and the constraints so that is is clear that XY, despite its known issues remains the clear and correct course of action.
On the other hand, there are times when people in the past have tried WY and decided in that situation Y was a bad idea. But your situation is X and it is quite different from what the answerer is familiar with from their experience with W. In this case you know X well, the answerer doesn't, and you know Y is what you want to do in this situation to solve X. The answerer assumes you're trying to solve W or something similar to W and you have to waste an inordinate amount of time assuring them your situation is sufficiently different from W in order to get a simple answer about how to do Y.
And that is why the onus is upon the person asking the question to explain the problem scope fully enough that anyone looking to help will be on the same page from the start and those who have encountered problems with similar approaches are aware that their experience isn't relevant.
Most often, the request comes in as:
> dev: How can I do def?
to which responses warning them of the problems with that approach and lacking the surrounding context are completely appropriate.
The issue is:
> ... Explaining everything involved in abc is a lot of work, and dev just wants to ask about def ...
Yes, it's a lot of work, but necessary to do either at the start or piecemeal consuming a lot more time overall between multiple people. To be respectful of other peoples' time, explaining abc is the correct thing to do.
dev: <tries to figure out how to do abc. Due to various limitations, dev comes to the conclusion that the best way to do abc is using def. Explaining everything involved in abc is a lot of work, and dev just wants to ask about def> How can I do def?
stackoverflow: Don't do def, it's bad. Have you considered xyz?
dev: xyz isn't what I want. I really just want to do def.
stackoverflow: Don't do def, do lmnop.
dev: lmnop won't solve my problem. I just want to do def.
stackoverflow: No you shouldn't do def.