I believe this was one of the main things he was actually trying to achieve - By embedding the linked list declarations inside the object, you can make sure to 'balance' all of them in destructors, and from a single place you can ensure that the object is never deleted without all references being removed.

I feel like this kind of problem is actually a specific instance of a much larger problem - that being explicit about these things leads to more maintainable code, at the expense of some 'leet things' that can cause troubles if not implemented perfectly.

He mentions that it's fine to call Unlink twice. Presumably the first Unlink zeroes out the prev/next fields.

Indeed, I may have read the code wrong. But look at line 188.

    m_prevLink->m_nextNode = m_nextNode;

I don't see where m_prevLink is changed. If the previous link has gone away, and you call RemoveFromList on this node a second time, it's going to chase that pointer.

RemoveFromList is a private method. All the public methods, other than the destructor, that call it also modify m_prevLink.

There's a better trick: point the link structure at itself. This avoids any need to test for null.