(CuF): Yes, JD1 had separate Enable/Disable menuitems and was able to show both when used on a mixed selection. JD2 has recently changed behaviour here - before and after are equally insufficient. The JD1 way (two independent menuitems) seems better for users, simpler to code, and simpler to get the menu editor right...

Something I've missed from the day I switched to JD2: JD1 would check new URL's against those in the DL list, whether completed or not. Sure, JD1 was too silent about why is would skip some imputs, but one got used to that.

My main gripe with JD: No true unattended mode. A user might want to leave JD running overnight and go to sleep, right? I do. What I want to tell JD is this: "Do start new downloads that have a chance to succeed without user input, but do not touch those where it is known in advance that user interaction is required."

Neither Silent Mode nor "Stop but finish" do this. "Silent" will start connecting to the hoster, request a captcha, then dismiss it. Recaptcha would up until recently punish the amount of requests from a single IP due to this behaviour by switching all captchas to the hardest variant (the inverting blotch / consonant-only ones) after a few hours. "Stop but finish" is not even a guarantee that no new file will be started, and it will not continue downloading links with premium accounts / autosolvable captchas or the rare cases where a resume can be done captcha-free. I guess I am saying both functions would benefit from far simpler implementations: Silent should fulfill the "user is away" usecase, while "Stop but finish" shouldn't bother flagging random files with the yellow flag but simply stop any new DL from starting.

Last one, really (JD is that good ):
JD will not always start the expected file for a given hoster (assuming free modes, single active file per hoster allowed), sometimes even ignoring priorities. This is good, as I guess there is logic to avoid JD choking on unexpected plugin errors behind that, maybe even attempts to avoid discarding a partial resumable download by starting an alternate mirror from scratch instead (at which JD still fails). Leaving JD running unattended in silent mode will definitely show this sooner or later. And - I see work is being done in this area, observed behaviour is changing.

My suggestion: JD should clear all such status information when the user hits the hard "Stop all running downloads" button, maybe even after a manual reconnect. Also, a manual change to any priority could clear said stati for all links using the same selected hoster. This would have helped all "insubordinations" I observed lately, where JD clearly started the "wrong" entries. Oh, and the bandwidth waste by unadvised mirror switches might be mitigated by having temporary priorities - boosting the prio of a resumable unfinished item by a virtual, internal half point?

And keep up the good work!