This is really a bug fix request. Two problems with the user interface are massive nuisances:

• Making multiple selections is broken and has been for ages. Control and shift clicks are interpreted correctly much of the time, but a random fraction are treated as plain clicks, and clobber your elaborate half-built selection, which is evil and rude. Moreover, shift-clicks sometimes do not extend a range correctly. Clicking a file and then shift-clicking a file way below creates a range as expected (when it doesn't just change the selection to only the lower file; we'll assume it worked though) -- now if you shift-click the next file down, it will frequently leave you with just the bottom two files of the intended range selected, rather than everything from the first file clicked on to the final file. (Sometimes it will just select that last file, but again that's the shift key being ignored rather than incorrect range extension.) This is unfortunate, because needing to extend a range by one is very common and control-click is far more likely than shift-click to hit the "ignored modifier" bug. As for why needing to extend a range by one is very common:
• Not only do the items move around constantly while trying to select from the list if there's a lot of activity happening, but the UI's response to your mouse clicks lags behind your input noticeably, and often enough for it to get the order of events wrong when the items shift. E.g. you click item A, shift click item C, and everything moves up one; but your shift-click is ignored until after the move, and you end up with A-D instead of A-C selected. If the shift-click happened before the move the consequences should be processed as occurring before the move goddammit.
• Clicking of "resume" or "find sources" is sometimes, incorrectly, ignored. The item is not greyed, and animates sensibly, but nothing happens.
• Recent versions of Limewire grey this button out sometimes. This makes sense for connecting and waiting in line, but I used to be able to select a download that had stalled and "resume" it; now it's necessary to make a larger selection that includes the download to prod a download into activity and even then it doesn't always work. Is it really intended that people no longer be able to resume stalled downloads unless they fail completely? Being able to prod a host that had apparently forgotten you were there with some kind of "keep alive" signal seems to be essential, since a download that slows down and stops is very likely to turn into a busy signal if you don't get it running again quickly, and since it is for some reason a very common occurrence for hosts to slow down sending a file to a trickle, and eventually stop altogether. (Often, when a host decides to start neglecting one of your downloads, the throughput starts dropping like a stone and reaches 0 without a single additional percentage point bein reached -- and usually the file will end up languishing as "busy" or "needs sources" for days, incomplete, if you don't get the rest of it straight away!) Maybe a better idea is to send a keepalive automatically if the throughput drops below, say, a quarter of the peak throughput observed for that file. So a file that has hovered around 3-4K/s that slows down will trigger an automatic keepalive signal (rerequesting the next chunk from the host? I don't know much about the details of the protocol I'm afraid) if it dips below 1K/s. Alternatively, send them if the throughput drops to a flat zero but not otherwise.
• Related: stalled downloads waste a download slot at one end and an upload slot at the other end. Sometimes, if the download turns into a busy signal it will resume at a decent throughput almost immediately when it is reattempted. For these cases it would be nice to have a way to stop a download that doesn't remove it from the list entirely, but instead bumps it from "downloading" to "connecting" status. The original download connection is dropped and a new one is immediately started that attempts to resume a partial file, to the same host(s). This would be for if "keepalive" isn't prompting any response from the remote host. (All too common.)
• Limewire developers can do little about most of the misbehaving clients that slow down and stop an upload and then let it languish, or suddenly interrupt one and send a busy signal, but they can do something about one such client: Limewire. Unfortunately, I frequently see this behavior from hosts identifying themselves as Limewires. Hosts that aren't misconfigured (exporting a 10.* or 192.168.* address) and with my own peer not firewalled, I might add.