Don't I know it; actually I was able to do all this, because I was in exactly that situation. Being able to code without pressure was really nice (though the code base was frustrating to say the least). However, it now feels like a dead end ... ready to be abandoned/giving up on.
So, I started by adopting birger (topic starters) last big series of patches. Split them up, clean them up; add tons of defines for a lot of magic values. Then, kept on adding more of those. Also marcus's patches I've added. Cleaned those up, added more defines. Tons and tons of rebasing sessions, trying to more logically organize them. So most changes are grouped, more or less with what you said. Not everything is perfect, but, I feel like it's an improvement overall. I'd almost say "merge it as is :p". I don't think there's any place that makes things worse, only for the better. However, I produce more patches then there is review/merge capacity it seems on the openwrt side ...
Yes/no/yes. So, the problem with the current code base, is that its a friggin mess. Everything needs to be rewritten to be upstreamable. It's not a problem, and I have started that on a few small things, but the difficulty here is, a) testing, b) validation, c) the mess that is the realtek chip 
E.g. does it work as it is supposed to. For something small, like the i2c driver that I have rewritten (which is currently in testing/wip as it's not working, but probably something small), is am I using the peripherial as they are supposed to. The reference (SDK/openwrt) code often does weird things, which are not correct, but seem to work. But who is right? So in doing things that should be logical right, it turns out, there's some weirdness where it simply doesn't work.
But more importantly, it's understanding everything. We have no proper documentation. The datasheets contain register descriptions, but not how to use things. And then there's the whole network stack, it's a mess.
So I have started to untangle a lot of things, and with the earlier mentioned defines, things actually become much more readable now. With that in hand, it is also now feasible to start re-writing things.
But, going upstream first/only, is a tricky thing. Nobody is using upstream in its current form. So validating that a new driver is correct, is hard. It needs testing, from more then just 1. Hence, getting things in openwrt (first in its current form, that helps is learn and understand) and later in mainline is crucial.
Also, having it in openwrt, means people actually get to use it and report issues on it. Putting it in mainline, makes it just sit there, with no users.
And yes, putting it in mainline, and then backporting it to openwrt is certainly a goal for the mid-term future, however, subtle differences, extra work makes that troublesome too. And again, just because upstream accepts it and merges it, doesn't mean it actually works
edit:
still over USB, but depends on the hour of the day 
[ 5] 6.00-7.05 sec 23.8 MBytes 190 Mbits/sec 0 221 KBytes
[ 5] 7.05-8.04 sec 22.5 MBytes 191 Mbits/sec 0 221 KBytes
[ 5] 8.04-9.03 sec 22.5 MBytes 191 Mbits/sec 0 221 KBytes
[ 5] 9.03-10.01 sec 22.5 MBytes 192 Mbits/sec 0 221 KBytes
though I doubt 200Mbit is possible 
