2 of 3 added clarification on drawbacks

Thank you for posting what I have been thinking of posting for weeks but have not for fear of being downvoted into oblivion (seriously). This would be a culture shift, but I have thought about this for some time, trying to make a strong case for it, and here is how I would suggest it should work:

As a trial, and since feature requests seem the most prone to problems, this is for feature requests. (Maybe it need only ever be for feature requests, but having different voting methods for different question types would certainly be confusing.)

A good starting point would be to start phrasing questions as questions, to exercise the normal SE instinct people have. That is, to only downvote questions if they show no research effort, are unclear, or are not useful. A feature request could be presented as a question outlining the problem and an answer with the actual feature request in it. The question could be of the form "What can we do to deal with [perceived problem]?" (or just "Dealing with [perceived problem]?"). This could be a good way to short-circuit the learned behaviour behind "voting on meta is different". ("Hey, this question is not a feature request. It's just a concern. I don't like the proposed feature request in the answer, though, so I will downvote that.")

That's just an implementation detail (though a big one). Here would be some reasons to implement voting on answers instead of questions, though, no matter how it ends up being done:

  • An advantage of this is that other feature requests that would same the same problem in the question. Alternate solutions to the problems inherent in feature requests are not captured especially efficiently in the present system.
  • Another advantage of this is that the questioner would have to think a little harder about what exactly the underlying problem is. This should cut down on proposals with little backing them up, but the main advantage would probably be the first one again: generating a wider array of possible solutions.
  • Of course, we would probably chase away fewer new users of Meta (and have to deal with less complaining and explaining that "voting is different") due to perception of established Meta users be mean. Voting need not be different.
  • What I would consider the main advantage of the new system would be adding information. We could distinguish between voting on the problem and the proposed solution. It seems to happen very often that good problems get dragged down by poor proposed solutions, when really those problems should be addressed.

Downvoting could be made free, by the way, for answers, in order to keep those free-flowing.

There are some drawbacks to speak of, but I think they are fairly small:

  • For some problems that really only admit of one solution (true single feature requests), it might look strange to fit it into the mold I am talking about. I think this is small price to pay for the advantages above, though, and of course some of the strangeness would fade with time.
  • I anticipate that finding feature requests and sorting them by popularity would become a bit more difficult since they would no longer appear in question titles and be packed together with their associated problems, but again I think the pros would outweigh the cons. Implementing a new, dedicated kind of search by feature request answer vote could actually be done to overcome the searchability problem. In the end, though, it may be that MSO fares better with answers being be answers regardless of searchability issues. (Stack Overflow might be a bit easier to navigate if the questions and answers were all lumped into the questions (and sometimes even the question titles), but that does not mean it would be a better site.)