I have observed practically all of the issued discussed above on my machine. Glad that I am not the only one. As long as the developers are aware of these issues (which is way beyond me), I am happy.

v6.10.xx is really bad when it comes to deadline-handling if runs multiple BOINC-projects, and will happily choose to run tasks for a project with 1+ month to deadline, while other projects tasks misses their deadline.

For other clients, on all tasks where "Connected..." > "time-to-deadline" the client will run the tasks in EDF-mode, so if "Connected..." is 1 day they shouldn't normally miss their deadline.

Where are some instances where computer will still miss deadline on some of the work. This can happen if has downloaded too much work, if estimated run-time is wrong, or if runs something other computer-heavy, or shut-down computer for some time or something. Suspending tasks or projects can also give deadline-problems. Getting GPU-beta-work can also lead to deadline-problems, since the GPU uses 1 cpu-core while running.


The problem is all the applications lying about the progress and how much time is left to do. Apparently some badly-behaving applications claims only 1 minute or something left to do, while in reality it's many hours left to do. Since BOINC-client also must handle these badly-behaving applications, relying on the claimed time left to do isn't possible and tasks is instead paused while other tasks needs high priority.

As for the task failing on resuming, this is strange, especially if left in memory while suspended. Still, seeing how many badly-behaving applications lies claiming no time left to do and shows "100% progress" but in reality is stuck in this state for several seconds, it's a possibility pausing at this point can lead to problems.

No good-behaving application should ever show "100% progress" before it's really finished.

At Sekerob's suggestion ( The CEP2 Forum > Re: Research Log: Updates from the Harvard Team ), I'm trying out BOINC 7.0.42 to use its new app_config.xml feature to control the max number of simultaneous CEP2 WUs that run.
Previously I've stuck with BOINC 6.2.19, and micromanaged execution of CEP2 by having only a small number of these in the cache, and fetching them to run as required. Sometimes I'd run out of CEP2 WUs and would have to temporarily nudge the cache value up a bit to force fetching some more. By default, 6.2.19 very helpfully reports the no of seconds of work that it is fetching, so I could see whether I'd fetched too much and take quick action to reverse this. Later clients don't report the amount fetched unless you turn on some verbose debug option that swamps you with irrelevant unnecessary info. This was a major reason for staying with 6.2.19.
With 6.2.19, I sort the BOINC Manager display on %Progress, and after downloading new work, the start order for WUs that are Ready to Start is generally FIFO and the displayed list of WUs at 0% Progress usually sorts in that order too. This really helps when micromanaging. However, 6.2.19 occasionally plays random shuffle with the cache display. This can be fixed by switching to "Accessible" View and back to "Grid" View.
Where are these View functions in BOINC 7.0.42?

In 7.0.42, WU start order seems to be vey haphazard, with WUs downloaded recently running while WUs downloaded more than 1 day ago sit still Ready to Start. Reading this thread it seems that this rot was there in 6.10.58 too. No wonder I get so many repair WUs with 6.2.19! Later clients delay execution of WUs and cause many computers to miss the "fast returner" threshold that qualifies them to be sent repair WUs.
Is there a way of sorting the cache display in to-start order in 7.0.42?
Is there a way to cause WUs that are Ready to Start to start in download order, excluding those at risk of missing their return deadline?
---
Also concerning WU start order in 7.0.42, I have a question re specifying max_concurrent for multiple sciences in the new app_config.xml file, but perhaps app_config.xml deserves its own thread.