Put a stateful table in there, and there is no problem identify most inbound traffic as high priority if the receiver first initiate the communication with high priority set. There is a bit of issues with mutli-path routing, but its a rare issue that could likely be ignored as non-QoS worthy packages.
Of course, that only work inside one ISP and its customers, or between ISP which agree to respect each other limited use of QoS, both this approach would not fall for the tragedy of the commons. So long the end-user who initiate the traffic ends up deciding what priority is needed, limited use of QoS could help solve problem of voip vs bittorent.
Routers (and bittorrent clients, and operating systems) allow households to prioritize their traffic already. (IMHO, any "solution" to bittorrent vs voip should live at the edge where it only affects the person who chose it.)
Read the Republic Wireless forums to see how many people actually understand the QoS settings of their router. These people are seemingly power users at the least, and certainly early adopters. Perhaps it's the acronym soup engineers expect the laymen to know, or perhaps it's the laziness of the typical end user, but I suspect it is a little of both.
That's just because many existing routers have bad UI. Some of them just have a checkbox for automatic QoS that works fine. AFAIK the bufferbloat/CeroWRT people are working on open source QoS that just works with no configuration. Downstream QoS really needs to be done at the ISP, though.
Of course, that only work inside one ISP and its customers, or between ISP which agree to respect each other limited use of QoS, both this approach would not fall for the tragedy of the commons. So long the end-user who initiate the traffic ends up deciding what priority is needed, limited use of QoS could help solve problem of voip vs bittorent.