Prompted by this question, which I flagged as "bug", it somehow doesn't feel right because the flag seems to be specific to "bug reports" and specific issues with an yet to be released version.
4That seems like a perfectly fine question to me. Just because a feature (might) not be supported by default doesn't make it a feature request. It also has an answer.– SethNov 1, 2017 at 23:22
@Seth You're right. My illiteracy is the culprit here (and it was unanswered when I posted this). It makes no sense after all.– user692175Nov 1, 2017 at 23:27
1Without looking at link it's still a good generic question because it led to Eliah's answer which I upvoted :)– WinEunuuchs2UnixNov 9, 2017 at 1:14
If someone asks how to do something that can't be done, and you know it can't be done and you can explain why or at least demonstrate that it cannot, then you can answer the question. If it can't be done but you cannot answer in a way that supports that in any way... well, then you might not know it can't be done. If something can't be done, or can but it's just a bad idea, then it is also reasonable to answer with an alternative--something else that's not quite what the OP asked for but which should achieve their goals. To avoid creating the impression that you're answering the wrong question, you can explain the relationship between what you recommend and what they asked for.
Whichever of these cases applies, a question about how to do something that there's no way to do is not the same thing as a request for developers to implement a feature for it. A question does not beome a feature request merely by asking how to do something that no feature has been implemented for. That question is not a feature request. (In this case, it also appears that it can be done--but your meta question about what to do in such situations is still a good question.)
For actual feature requests, where someone posts on Ask Ubuntu to say what they want added to Ubuntu, that's not even a question. In cases where you're really sure that's what's going on, the best thing to do is to briefly explain or link to resources about how to file feature requests. In practice this is largely the same as if they had attempted to report a bug, because some missing features are effectively bugs, and because even feature requests that aren't bug reports at all are covered in the official page for bug reporting, which I suggest you link people to, even though the recommended course of action isn't to file a bug.
Finally, sometimes users will ask how to file a feature request, or they may ask a question about what they should do if they want a particular change made and the answer might turn out to be, "File a feature request." (Ideally, with a bit more information included.) These are perfectly good questions for our site. Some may turn out to be duplicates, and others may require their own specific answers. This is similar to questions asking about how to report bugs, or if a particular behavior is considered a bug and ought to be reported.
I'm not sure if I'm strictly adhering to on-topic here but there are many instances when someone asks for a new feature and Serge or someone else (in the rare case myself) will write a solution for them.
This is probably a case of a "new function" or "new program" request though. There are people who can / will take an existing full-fledged application and can modify the code for you / them but I honestly don't know how often this happens as I'm rather Git-Hub-Fork-Challenged so far.
Another thing to consider is there might be another way of accomplishing the end goal without following the "feature request" game plan of the questioner.
I guess my answer is we should be tolerant / open-minded about "feature requests".
1This is a good point. The distinction I would make is between requests for a feature to be added to Ubuntu and requests for how to do something where the answer may be, "There's no feature for that but here's an implementation you can use." Nov 9, 2017 at 3:12