Did you come here for support? Leave out all the laments of suck, stupid, hideous, annoying and just give the problem details and we'll get going with it!

There is at least 1 FAQ explaining how to avoid generating a new device. If it did create a new host entry, 1 or more of the 6 elements that WCG tests did not match.

http://www.worldcommunitygrid.org/forums/wcg/viewthread?thread=16521

I quite understand where you're coming from on that, and I'd feel the same way in your position. However, don't forget that WCG isn't there for my personal benefit either.

A hard drive fails. Time to reload from backup: About 3 mins. Everything works perfectly ... except WCG. Okay, maybe it doesn't link the symlinking? Time to re-partition one of the other drives in the machine and reload from backup? About 10 mins. WCG still not happy ...
* creates new cpuid for no obvious reason
* doesn't say why it's done it (if the message from the server said what the mis-match was, I could try to make it happy)

Time of mine wasted trying different things: About 2 hours so far. All because software which doesn't benefit me at all behaves in illogical ways, is poorly documented and doesn't explain what it's doing. I've said it before and I'll say it again: this boinc setup works great under normal circumstances, but under some failure conditions which should be dead simple to recover from, it's an absolute dog.

That appears to be untrue. Nothing whatsoever about the hardware or networking have changed in the 2 days since my last backup, including none of the 6 items which are supposed to be checked according to the FAQ.

However, I have fixed the problem. So, here's a recovery procedure for anyone else who experiences this in future:

1) [optional - so as not to be messy and download tons of WUs we're never going to process] The machine in my case was not using the default profile, but a machine with a new CPID will use default. Set the default profile not to get any WUs. ie. Set it to AC@H only.
2) Restore data. Remove WU data (ie. slot/?/*). Remove all entries from client_state.xml concerning currently running jobs. ie. The "file info", "workunit", "result" and "active task" stanzas. Save this copy of client_state.xml.
3) Increment "rpc_seqno" in saved copy of client_state.xml and copy the file to boinc data directory.
4) Run Boinc. If it reports generating a new CPID, kill it and go to step 3.

Once you hit the right rpc_seqno, the server will supply new copies of the WUs the client was working on previously, and work will continue from the start of those WUs again.

They certainly are related. In this situation, when it creates a new CPID, it creates a new hostid, new rpc_seqno, etc. Then you have multiple devices with the same name in the Device Manager, some of them with one profile and some with another. It's a shambles.

Firstly, it is true. Please don't waste my time and try to mislead others by telling me I'm not seeing what I'm seeing.
Secondly, no, I don't really want to waste more time "learning" why. Feel free to research it if you want.
Thirdly, while we're at it, don't tell me that I'm "confusing" CPID with host ID. client_state.xml contains different host_cpid and hostid than before.

There is, self-evidently, a relationship between the two, in that they are both changed by some process that is triggered by the situation and they are the only significant variables that are changed. What the mechanism(s) are, the user shouldn't need to know. Assuming that the messages from the server are in chronological order, the host ID gets changed first. This is not explicitly reported by the server. It is only implicitly reported if, as in this case, the location (aka venue) changes. The new CPID gets then gets assigned for this "new" host. However, the CPID is the only one explicitly reported in the log, which is the reason I mentioned it. The change in CPID is reported in an obvious manner to the user, but for the change in host ID, you have to dig around in the client_state file.