Now I remember why vtkCommand is not treated the same way as other VTK objects. vtkCommand and descendants do not follow the same discipline as most other VTK classes. Specifically, they do not use vtkStandardNewMacro nor vtkTypeMacro. The first defines the static New() member function that fully constructs a VTK object and then registers it with the leak manager. If the object is not fully constructed when GetClassName() is called, then GetClassName() returns the name of the superclass (I think). The second macro makes the VTK class aware of its name. Even if the name is known, however, it is not available at the time the object is registered with the leak manager. We cannot register the actual vtkCommand objects based on their names because of this. If you try to register vtkCommands with vtkDebugLeaks::ConstructClass(vtkObjectBase* object), you end up with incorrect reports that certain object types are not known.
If vtkCommand and subclasses were cleaned up in VTK, that would help a lot. However, there are bound to be a lot of applications that define custom subclasses of vtkCommand that won’t be updated and could lead to spurious warning messages from vtkDebugLeaks.
For now, I will not make the stack tracing mechanism work with vtkCommand and children.