Release, Dealloc, and the Self reference

A1) [nil release] is fine (won't do anything)

A2) No. Don't touch objects after they've been deallocated. They should be set to nil after they are released.

A3) It's not necessary to set a released pointer to nil, but you get dangling pointers (i.e., you can't tell if an object is valid or not). Setting a property to nil is often used to release the underlying ivar, so failing to do this can cause a memory leak

A4) nil and NULL are both zero, so are technically the same.

A5) Yes, you must use self.someProperty for properties, just as you would use [self someProperty] if it was just a method

A6) self is essentially a struct, so you can access ivars like so: self->someIvar. There is no need to, though.

A7) When you don't want to run the setter/getter methods for whatever reason. I use it ocassionally when the setter doesn't allow nil values, and I need to release the variable

A8) dealloc is called automatically when release is called the correct amount of times. You should never call dealloc directly (except for [super dealloc])

You should probably have split this question up into multiple different questions, but I'll bite.

1. Yes, any message sent to nil is a no-op.
2. No. An object with a ref-count of 0 has been, or imminently will be destroyed and any messages sent to it will cause a crash, or at best, an exception.
3. It depends on the situation. If you're releasing things in -dealloc, then probably not. If it's an object that is scoped to a particular method, then probably not. If it's an ivar that is reused, I'd say yes. In the first two cases, nothing will happen if you don't set the pointers to nil, since you usually won't be able to access those pointers anymore. In the last case though, you still can access the pointer, which is pointing to deallocated memory. If you send it a message or try to dereference it, your app will crash.
4. They are both equal to 0. By convention nil is used for object pointers, and NULL is used for any other pointers, but mixing them won't cause any problems.
5. If you want to invoke the property getter/setter, then yes. If you want to access the ivar it encapsulates directly (uncommon), no.
6. No, you can access instance variables using the syntax self->ivar. In fact, when you type just ivar, the compiler implicitly adds the self-> dereferencing.
7. Not sure what you mean here.
8. The only time you should be calling -dealloc is when calling [super dealloc]; in your own -dealloc methods. For any other objects you should always just call -release.

Others have answered 1-6 adequately.

(7) Apple recommends you use the instance variable directly in both your init and dealloc. Primarily this is because the object (especially if it is subclassed) is only partially set up during both of these methods, and so calling setters/getters may result in incorrect behavior if they have anything other than trivial actions. Generally you can safely access the ivar directly (rather than via the getter) in your object, and it will be marginally more effecient to do so (only relevent on the iPhone). Generally you should use the setter in all cases, especially if your object may be subclassed or if others may be observing the property.

(8) You never, ever, call dealloc (except [super dealloc] from within the dealloc method). If you have an ownership on another object, then you should relinquish that ownership (by calling release or autorelease). The system will then call dealloc on the object if appropriate. But you never call dealloc yourself. Read the memory management rules (its only 9 paragraphs and is vital to understand).