Something else observed.
Because of this behavior of BOINC of taking a long time to settle down and adjust downloads to meet the clients wishes. Then it becomes apparent that the download limits on counting tasks is probably not the correct course when tasks take differing times to process.

To limit the number of downloads, and hopefully not cause too much disruption if I made a mistake, and that can be frequent, I set the cache to a low level 0.1 days + 0 extra. Relying on my backup project Einstein, with a resource share of 0, to fill in when Seti was offline.

Through all this I discovered that Beta has a download limit of 50 tasks. This took up ~100 minutes of my cache144 minute cache (0.1 * 24 * 60 = 144). And that equates to ~10 tasks availble for Main, because most of what we are presently processing is Green Bank VLAR's. Not a good state of affairs IMO.

But it could be a lot worse, Beta is processing VHAR tasks, hence the 50 tasks, 100 minutes.
IF Beta was also processing VLAR's then Beta would have swamped my 144 minute Cache, 144 / 4.5 = 32 VLAR tasks. That is well below the 50 tasks limit. This combined with the 305 sec communication deferred and a Main VLAR processing time of ~270 sec problem, (i.e. comms defer time is longer than crunch time even though these are our longest MB tasks) would mean at best the computer would have been alternating between processing Main and Beta further upsetting the resource share calculation.

Therefore IMHO, the observation indicate that;
A. the download limit would be better if it was calculated on expected processing time not number of tasks,
B. the communications deferred limit needs to be shortened, or better still only applied for a limited period after an outage.
C. the resource share should play a bigger part in what gets downloaded next, possibly stopping downloads from all projects until the countdown has completed.

N.B. I have increased my Cache to 0.25 days, so that I have a reasonable amount of Main tasks, based on my logic and calculations,