Clean install vs. archive and install?

Question

I did an archive and install of OSX to try to solve a stubborn problem with a 3rd party program. No dice, so today I tried a clean install.
I was surprised after the clean install completed that I got an iCal reminder and most of my other system settings were still in place. I thought a clean install was more thorough than that. it still didn't clear up the problem with the 3rd party software, so I guess the next step is to backup everything and do an erase and install.
What exactly does a clean install do? I thought it was comparable to restoring the OS to factory-fresh condition, but it doesn't seem much different than an archive and install.

Answer 1

Obviously this does not happen because it is common for previous settings and configurations (as well as the issues that the user performed the "Erase and Install" to eliminate in the first place) to remain in place after an "Erase and Install" is completed.
Everything remains 'in place' after a normal erase except the info that tells the file system where the erased item is on the drive. The OS finds the actual data the file contains through the file system, which keeps track of the logical sectors on the drive that make up the file. When a file is "erased," all that happens is the file's entry in the file system is erased, freeing up the sectors the file used for new files.
The *only way* the OS could somehow mistakenly retrieve even a part of a previous settings file's or any other file's data is if the file system is corrupted, meaning it contains incorrect info about one or more sectors that contain an active (un-erased) file it is trying to access. Understand that the sectors just contain ones & zeros, whatever they represent in terms of executable code or data. The name, file type, & all the other info about it is in the file system. The OS has no way of knowing where a file's data used to be or what it was used for except through the file system.
So, the chances that corruption in the file system would somehow exactly point to an old settings file's sectors and they would be in the right order and the file the OS is trying to access is also the same settings file are vanishingly small. This is the only way the OS could mistakenly use the old settings file -- anything else would cause the OS to choke on the file because the zeros & ones are not in the correct order to represent that same settings file.
With this in mind, it should be obvious how bizarre the idea is that zeroing out the drive somehow prevents this from happening. It absolutely doesn't matter in the slightest if the 'bad bits" are all zeros, all ones, or some combination of the two. If the drive is zeroed out, every bit returned will be a zero. If the file is supposed to be an XML-formatted preference file, all the OS gets is a long string of null characters, lacking the required XML header, & the OS chokes. If it is supposed to be an executable file all it gets is NOP's & the zero address, & the OS chokes.
Simply put, in the digital world, zero isn't "nothing" or a sign that the computer should ignore it, it is one of only two possible values a bit can have. All useful code & data strings are made up of zeros & ones in exact patterns. Any string of all zeros is no better or worse than a random sting of zeros & ones unless it is exactly the string that the file should contain, & there are no useful files that should contain all zeros.
What users do need to do if there is any question about the wrong data being returned is to replace or repair the file system, not futilely write zeros to the sectors it should be keeping track of. An Erase & Install *does not do this*, which is why that step alone is not enough to fix this problem.