Hello!
So I'm here for my bounty! 
Seriously, the dropped frame issue is caused by a race in the ieee80211 -- but it's apparently a race that they know about and don't care about? I've sent a message to linux-wireless with a patch that is probably going nowhere. Apparently, despite the lacking API documentation, we're supposed to just drop them on the floor when our struct ieee80211_ops.tx is called and our queue is full. ieee80211_tx_frags is perfectly capable of queuing the damn things up and we could even shove them back in the 80211 queue when the driver queue is full, but noooo...
I guess it's a performance thing of not wanting to hold another lock -- I'm sure there's a way to mitigate that too, but whatever -- we just need to get to properly documented.
So more specifically, the driver sometimes continues to receive frames even thought it has stopped the queue because multiple threads have been preempted after they already checked to see that the queue was running, but later blocked when they hit spin_lock(&queue->tx_lock); in rt2x00queue_write_tx_frame(). So probably the most ideal solution would be to not lock anything in the .tx code path if that is at all possible, which is probably isn't 
Either way the solution to the slight problem of the system going to hell in a hand-basket is to just not scream "I HAVE AN ERROR EVERYBODY, STOP AND LOOK!" when the system already saturated. Don't worry, I've done it too, lol! We just snip this:
rt2x00_err(queue->rt2x00dev, "Dropping frame due to full tx queue %d\n",
queue->qid);</pre>
This should keep the driver from dying, but not from lying. I think mac80211 needs a:
static inline void ieee80211_tx_mic_drop(struct net_device *dev, u32 len)
{
struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats);
u64_stats_update_begin(&tstats->syncp);
tstats->tx_dropped++;
tstats->tx_packets--;
tstats->tx_bytes -= len;
u64_stats_update_end(&tstats->syncp);
}
Because at current the stats are pretending that everything was sent just fine.
We'll see what happens tomorrow.