This is probably the easiest culprit to eliminate: the size of the stdoutdae files is more or less constant and BOINC is simply pushing message lines out as needed to fit with this size. So the difference between the log file of a very busy client (like our multicore ones with HCMD2 currently) and a very quiet one like a very slow machine is only the number of days of activity which are kept.
Currently the stdoutdae.txt of my quad contains about 15 hours of activity (without checkpoint logging) while that of my eeePC (which I removed from crunching in September 2011 ) contains messages covering 15 days with checkpoint logging!

No, I do think that the problem has to do with communication between the client and the server, i.e. when exchanging the client_state.xml files between both after an update request.
If latest changes on the server side improve the ability of the server to deal with the big update activity generated by the small grand children HCMD2 WUs currently, maybe these BOINC client failures might be over. Otherwise we will have to wait for the end of the HCMD2 final cleaning, or for a better designed version of the BOINC client which would simply drop/ignore the returned client_state.xml when it is corrupted or incomplete and retry the update request from the beginning.

Bad guess from my part: it just happened again and this time there was no update request in progress, only a mere upload of a HCMD2 result:
Started upload of CMD2_2175-1NZW_A.clusters.....
Can't open client_state_next.xml: fopen() failed
Couldn't write state file: fopen() failed; giving up

No user activity either and the number of tasks in the cache was the lowest of all these last days, only a little more than 500, and about 30 WUs ready to report.

Same here, getting no more work-units on one of my HCMD2-only machines - the other downloaded a huge chunk of other WCG units, before I set it to HCMD2-only.

Also showing the project as down for maintenance, with uploads disabled.

We are still catching up on various backend tasks due to our problems earlier in the week. HCMD2 is loading up work now and since we have resolved our issues, you should have a steady stream moving forward from here.

Because of several daily hang-ups for each Linux-based host, I deselected HCMD2 for the next 7 days. I have to business travel and I will not be able to baby sit the hosts.
The hang-up issue seems to appear rarely on Windows-based hosts but too often (around every 6 to 8 hours) on Linux-based hosts.
I am a little bit frustrated since I need around 200 crunching days for achieving 30 years on HCMD2.
Cheers,
Yves