If you go with an Apex REST Webhook on a public Site, note that there are several headers which are not allowed (cookie, set-cookie, set-cookie2, content-length, authorization), so you won't be able to use those, you'll have to come up with custom header names to validate the traffic. Not a problem with custom traffic, but if you're trying to support some existing notifications that only have the capability to do basic auth headers, that might be a problem. developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexr‌​ef/…

Actually manually deactivated a user, saved, then updated their email and saved again, and even that is still sending the email confirmation.

Has anyone tried this recently? I'm not seeing this work, I ran a very similar script, and it's still sending the confirmation email for the change.

Actually I just found this (wiki.developerforce.com/page/…), which suggests that the "What to do if the lookup record is deleted?" setting has a strong impact on locking behavior for lookups. Off to do some testing...

Are there any performance considerations to be made between Lookup and Master-Detail, or between the configuration of each of those (e.g. required vs. optional lookups, re-parentable M:D)?

Yes a lack of Read access on Contacts would certainly cause them not to be able to see the records.

Interesting adjustment to this, in Winter '14 they are removing the script statement limit! It's being replaced by a limit on the overall time a process can execute. Perhaps your code will run just fine on a Winter '14 build.

Can you instantiate a list of wrappers in the same way? I'm having trouble getting this to work in my test class -> List<someExtension.someWrapper> localList;