Anderton
As far as I can tell the majority of people are not reporting corrupted projects, so it's unlikely the software by itself is the problem or there would be many more reports. I've had one corrupted project that I can remember since Sonar 1.0, and was able to recover it so I don't know if that qualifies. At this point we're grasping at straws, but an experience I had with the Mac may be instructive.
As we all know, Macs are Perfect and never crash because they are Perfect 
. But I kept having weird, and extremely intermittent, crashing and file corruption problems. I lived with this because the issue was rare, but every now and then I had to re-install the OS and start over.
To make a very long and frustrating story short, someone (it was either here or my SSS forum) suggested checking the RAM. So I checked the RAM, and it was fine.
BUT then it was pointed out to me that the only way to REALLY check the RAM on a Mac was via the command-line interface, because otherwise, I'd be using RAM to load the program to check the RAM. Or something like that. So I found a way to test RAM from the Mac's CLI.
Son of a gun. One of the RAM sticks had a problem. I replaced it, and my Mac has been working fine ever since. I have since become a proponent of "No, the cheapest RAM you can buy off the internet is not necessarily the best option."
Craig, let me just state upfront that the problem is rare, and difficult to reproduce. I've been using Sonar since version 1 and it's happened at one point or another throughout multiple versions of Sonar (most recently with X2) across multiple systems. I'll bet that if you took a poll on these forums and asked "Have you experienced corrupt projects in Sonar" you'll get a larger number of responses than anyone would care for. I can see 3 threads just in the last week that reference corrupt projects. A forum search yields much more results going back years (which lines up with my experiences).
Now with the above said, unless my PC crashed during a save, my hard drive died, or the power was unexpectedly cut, corrupted projects should never happen. Ever. Otherwise, if something is failing in the save routine, Sonar should not commit the save. The save process should first perform a check to make sure the save was successful, THEN commit the changes. If not, display a "Save Failed" error message and don't apply the save, this would at least alert the user to the error and allow them to the necessary action.
By just essentially saying "it's got to be bad hardware, it doesn't happen to me" doesn't mean it's a non issue, nor does it mean the problem isn't in Sonar's save routines or project file format. Look at the "loops don't stay in sync unless the metronome is on" thread that you participated in just a few days. It was reported by multiple users, you tried (very much to your credit) to reproduce the issue and couldn't, and suggested that it might be a zero crossing issue. However, if the loops were loosing sync due to a zero crossing issue, then turning on the metronome wouldn't resolve it (and the OP confirmed that it wasn't a zero crossing). So there's clearly something going on here, that's not manifesting itself in all scenarios or systems, but it doesn't mean the hardware is at fault, it just means Sonar's not doing it on your machine. Some software is more "sensitive" to different hardware configurations than others, but that doesn't make the hardware at fault.
And finally, as I indicated in my post in the other thread, I've just never had this happen in other DAW software. Maybe that's just luck, but I suspect there's something that can be done under the hood in Sonar to bulletproof the save process. Perhaps just putting something out there on these forums that says "if you have a corrupt project 1) tell us what happened and 2) send us the file" might help diagnose the problem, being that it's so rare and difficult to reproduce.
Just like Noel went in and took a look at the VST code, fixing a lot of bugs to increase stability, it couldn't hurt if someone did the same thing with the save routine. Maybe they'll find bugs, maybe they'll find some way to verify a save was successful before committing it (like a checksum type routine), maybe they'll look at the code with fresh eyes and decide that the CWP file format is a bit outdated and it's time to update the default project file format to a more modern standard (perhaps something XML or .txt based). Then again, maybe they won't find anything. The point is, there's enough anecdotal evidence on this forum to indicate their could be a problem, and the only thing it cost is a few hours of one or more developers' time. Those few hours seem like a worthwhile investment to me.