So basically every project then?

I WANT my phone to phone home you insensitive clod!

And another possible hypothesis to test is that a pay cap will stop these jobs from attracting highly social manipulative psychopaths hell bent on just getting rich at the expense of everyone else, instead of actually running a company properly.

If you were responsible for the key, and lost the key, you might very well be liable for the damages caused by having lost the key. If it was Terry Childs' responsibility under a reasonable interpretation of the terms of his job contract to ensure continued access to the servers (and it seems that's along the lines of what the courts have now decided) then he was in violation of his employment contract for actually doing so.
It was potentially naive for the employer to trust him with this much power, but it's equally likely they had no technical idea that this was the case. The only other option beyond trusting your highly skilled employees is to have at least two people for every job, and then hope they don't actually collude to cause trouble anyway.

The contract doesn't magically disappear into thin air - it ends under the termination terms of the contract. Those are almost certain to state that you are required to return all property, physical or intellectual, that belongs to your employer and you were granted access to for the purpose of performing your role. The passwords are quite obviously important intellectual property of the employer. The "getting hit by a bus" case is irrelevant in this particular case (even though correct planning for it would have prevented Terry Childs from holding the passwords hostage) - Terry Childs wasn't killed and didn't disappear off the face of the earth, he was fired and was still required to follow the termination terms of his contract.

Um, dude.

If you think C++ is simple or intuitive you haven't used it enough, and/or enough of it. There is nearly always some dark corner of the standard that does something which is at first glance totally illogical until you understand the way the compiler or history has had to deal with the construct in question. The most vexing parse, for example, or the fact that there are three char types (char, unsigned char and signed char are distinct types).

Most "precisely engineered" stuff that's actually engineered is still the product of large quantities of trial and error, at some level :)

You can teach the facts of religion, in unbiased form, perfectly fine. I know this, because I've witnessed it, in a Catholic (!) school in the UK. They covered most major religions and the differences between them, without claiming any of them was right or wrong. No, Catholicism didn't get preferential treatment in that class. Faith and religion are important factors in most societies and covering them (correctly) in school is probably a good thing to ensure well-informed individuals.

By the time they've read it they probably *want* to die.

Shortcut-based or screen-edge-based snapping is several orders of magnitude faster than tweaking window sizes to actually fit two windows to each fill exactly their half of the screen. It gets even more fun when snapping on multi-monitor setups - which you can do on Win7 using the windows-key/arrow-key shortcuts. It matters. I do it hundreds of times a day when developing, debugging, or writing documents.

The OS supports 32-bit systems with up to 4Gb of physical memory, but you cannot get more than 3GB of virtual address space for a single process in XP, and that is if you use the 3GB switch and the process was compiled to be large memory aware, otherwise your XP process is limited to 2GB.

Dissenting opinion: I ran Vista Home Basic 64bit for a long time. No eye-candy (it's not in Home Basic), not that many system requirements (because all of the "cool stuff" I didn't want wasn't included anyway). It worked just fine. I never noticed much difference between Vista and 7, just some tweaks of features that were actually in Vista, and some small usability upgrades such as the task bar with pinning (which I like, it has uses). I think Vista just broke the ice in terms of the new driver model to support 64bit, and lots of people were annoyed at 3rd party manufacturers just not being up-to-date with their drivers.

I've got no real beef with XP, but it's not "magically perfect". I happily ran Win2K WAY past its sell-by date back in the XP release days because I disliked the default candyland look and feel and 2K was fine for my purposes. I have also recently installed a Windows 7 32-bit on an ancient machine with an Athlon XP3000+ processor, and it ran incredibly smoothly considering how old and "windows 7 unready" the hardware was. I understand the frustration at the EOL forcing an upgrade when what you have works perfectly fine, but I sincerely doubt there are real technical reasons for XP to be "better" that actually apply to many people beyond emotional responses to change.

I understand your sentiment, but it's not the only way to solve the problem of the state of "pushing the envelope" code. I encourage my engineers to give any solution they've implemented a second look, immediately after finishing the implementation, and if they have any sort of misgivings about the complexity, quality, documentation, completeness or any other feature, do it again. This is supported by instant code reviews by other engineers who will also voice their misgivings about those features.
It usually takes very little time to re-do a fresh implementation, even if it is from scratch, and it means that hours or days after the "first" version we're already on the second or third, and this version is so much better and simpler than the initial one it surprises us a lot of the time. Not coincidentally, the code often also changes from "pushing the envelope" to "oh, there's a solution that doesn't require any trickiness". But the engineer has pushed their envelope on production code with production problems, and all involved will now know the simpler solution the next time something similar comes up.

No you don't - at some point the other party will stop waiting for your answer and walk away, terminating the process.