The basic problem is that you have your cache too high. The fact that you have a WU that is due on Jan 6 th and today being only the 27th, says that you are trying to cache for 10 days (or close to it). I suggest that you reduce your cache to a more reasonable level. If you have regular internet connection, the recommended level is 1 or 2 days.
By having such a high cache, you also run many risk, one of which is not finishing on time, another is that BOINC can start acting funny (such as jumping back and worth on multiple WUs).

Edit: I meant that you have high priority work that is due on the 6th and today is only the 27th

BOINC will run WU in the order in which the come in not when they are due. The ones that are due on the 30th or 31st are repair jobs. They will be run just like any other WU, as in the will be run when it is their turn (in order of first come, fist served). The only exception is if you decide to bump up your cache to 3 or 4 days (or you complete an extra-extra long WU making BOINC over-estimate the time it takes to complete the remaining work). Then BOINC will worry that it may not finish those WU on time and make them high-priority, thus running them first.

Thanks for both replies. Yes, everything will probably work out due to the math, but I will keep an eye out for what is happening with the nearer-due-date WUs.

I thought maybe there was a year-end problem, with 1/5/2011 dues dates seen as being higher-priority (sorted before) dates like 12/27/2010. But Boinc has been around for awhile, so...

I will look around for an explanation of what a "repair WU" is.

And yes, I've found that a cache size of no more than 2 days is fine for a stable, well-run project like WCG. For less stable projects, you never know when WU's will be available, etc. so a much larger cache size is needed to avoid running out of work units while the less stable project is down, etc.

My case is complicated by allowing half the CPUs on both of my devices to be used by Einstein@home (because it gives more credits - per day per CPU - than WCG does), and half to be used by WCG.

BOINC does seem to work better (if something seems to be going wrong) after being turned off and then restarted, or after a reboot of the device. Once it gets into a steady-state after a day, all seems better.

Einstein@home right now seems to have two internal projects going, with work units on my faster PC that take 6 hours for one project, and WU's from the other project that take 16 hours.

The WCG projects I have selected have work units that seem to run from 4, 7, 11, and 16 hrs each. I believe this complicates things too, as far as Boinc scheduling of WU's goes.

I do not know what would happen if I decreased my cache (a device level setting, not by project, etc.) to 0.1 day. Would work units from Einstein@home (or WCG) take over all 4 CPUs of my PC? Would any WCG work units be downloaded to run? I suppose that this is why I've left my cache at 1.5 days so there are a few WU's around ready to go from both Einstein@home and from WCG so that 2 of my 4 CPUs will remain devoted to Einstein@home, and 2 will remain devoted to WCG.

There's always the suspicion that I should not pay too much attention to all this and just let Boinc, WCG, and Einstein@home battle it out and do their thing, and that over the long term things will work out OK. It is interesting, however, and fun to check in one once or twice per day.