Another thing. What's with Limewire sometimes being confused about whether or not a Bearshare or (especially) Shareaza host is nonexistent, or merely busy? Very often I see a bunch of busy hosts files go "Connecting ... Awaiting sources" as though it retried them only to find the host had gone offline. But often, selecting them and hitting "resume" produces a bunch of "busy hosts" again -- so the host is not offline. So which was it, offline or not offline? Is this Limewire incorrectly distinguishing busy signals from timeouts? Shouldn't it give up on a source only if a connection times out? It clearly gives up under other circumstances though -- sometimes I see it give up in a fraction of a second, not the 60 it takes to time out, after resuming one.

Or maybe the problem's with some other clients. It seems to happen mainly with Shareaza and, to a lesser extent, Bearshare sources, suggesting these clients might be sending spurious 404s as a way of saying "I'm REALLY busy" or some such rot. (Yet, it sometimes does that with one file, gives another a straight busy signal, and queues a third while actually uploading a fourth in a group of files -- it's weirdly inconsistent.)

My theory on this is as follows:
Busy is busy. Don't send something else to mean busy, or let the connection time out when you're there.
404 means "I don't have this file", not "I do but I'm busy". See above.
Queued means queued. Unless the source goes offline I want to see that position number decrease steadily and then the file download. All too often I see it increase, or change abruptly to busy or even awaiting sources. Commonly, selecting it and hitting resume puts it immediately back into the queue again at some high-numbered position. So the host hadn't gone offline. It just decided to kick me back to the end of the line for no reason at all. That's incorrect behavior and probably violates a few RFCs.
Downloading means downloading. I don't want to see any more downloads that abruptly turn into busy signals at suspiciously round fractions like 1/3 or 3/4 of the file sent. Once you start uploading to a host, the only excuse for not finishing is going offline IMO. And none of this fractional-KB/s bullshit either. Shareaza is especially bad for being stingy with upload bandwidth but many hosts upload very slowly after advertising cable or better speeds. Then there's the ones where the download progresses reasonably at first, but after a while the kb/s starts going down and the time stops counting down and starts counting up. Resume often makes the slowing-down download return to normal speed, but left unchecked it commonly goes all the way to zero. I guess these hosts want to make sure you really, really want the file or they'll give the slot to another host? Since usually if you don't keep hitting resume every so often, it slows, eventually stops, and then you get a busy signal. I want this kind of crud to stop happening as well. Shareaza is bad for it but I've seen downloads from other Limewires exhibit the "slows down and eventually stops if you don't keep hitting resume" effect. Any developers listening, if that "feature" isn't gone in current limewires, it better be gone in 4.0.6 and subsequent versions.

Anyway, besides seeing Bearshare and especially Shareaza fix their shoddy software to stop doing some of the above bogus things they seem to be doing, I'd like to see Limewire's developers overhaul the downloading code. Firstly they need to make sure the status determinations are accurate -- that it doesn't show "Awaiting sources" when it gets a busy signal from a source, that it doesn't do anything itself to slow or halt downloads such as not ack arriving chunks in a timely fashion. Removing the "it spawns dozens of threads and the event handling thread hangs for ten minutes" bug should fix most of the problems with downloading from other Limewires as well as some problems downloading from any source at all.
Maybe there's even some way to cover other clients' misrepresentations of busy/nonexistent status somehow, and make up for these clients' deficiencies.

Then there's clarifying the distinction among two of the states: need more sources and awaiting sources. As far as I can tell, the only difference is that the latter can be resumed while the former can be requeried. The actual state of the file is exactly the same: Limewire knows of no hosts for the file that don't time out when attempted. In this case, requerying makes more sense than resuming as the user-available action; if the sources it knows of have all gone offline or become overloaded to the point of timing out, new sources are desired to get the file, rather than retrying the existing ones. Therefore, the "Need more sources" state and its user available options makes perfect sense. "Awaiting sources" just seems to mean "Need more sources and requeried already since the last time Limewire was restarted", and there's no logical reason to distinguish this from "Need more sources" in general. In fact, since requerying is the only likely route to acquiring the file, there's a good reason to stop distinguishing it, and provide "Find more sources" rather than "Resume" as an option. Better yet, provide both -- since sometimes some clients lie about file availability and you end up with "Awaiting sources" showing by a file that clicking "resume" will cause to download immediately, until those buggy clients stop lying and the older versions of them that lie fall into disuse, providing both options makes a lot of sense.