Uhm... those are two different interfaces but they were already implemented in the same COM object aka struct ConfigFileHandler. See my first patch were the AddRef and Release methods were already forwarded from ISAXErrorHandler to ISAXContentHandler. So I just cleaned up COM for the single COM object.
A COM object is not the same as a struct. A single struct can implement multiple COM objects (we do this for many interfaces in windowscodecs where we have a "container" object that always contains at least one child), or a single COM object can be implemented via multiple structs.
The identity of a COM object is determined by the result of calling QueryInterface with IID_IUnknown. In this case, QueryInterface returns different IUnknown pointers for each interface in the struct, so they are different objects. This imposes some requirements on their behavior, but there's no requirement that the refcounts of two different objects be unrelated, or that the reference counting be implemented in any specific way.
There's no reason they have to be different objects here, but there are many other structs in windowscodecs that implement multiple COM objects which must be separate.
The alternative is to split the struct ConfigFileHandler. But as this is not part of the API/ABI and the applications cannot get to those COM interfaces it doesn't matters. Also the ISAXXMLReader just needs the two COM interfaces, how those are implemented it doesn't matters either.
There's no requirement that a single struct can only implement one COM object. The implementation of most encoders and decoders in windowscodecs is greatly simplified by putting multiple objects in one struct.