That seems easy enough to fix, just move that variable into global scope and clear it on destruction. There may not be a known application that relies on it, but no reason to add todo_wine to a test when just fixing the code is easier.
There is no reason to have such test to begin with, same as trying to match refcount values. It's clear and more straightforward to have a new instance every time, or a static factory. Using something global then brings a question about safety, why would we go there if we don't need it.
Maybe it would have been simpler to do it a different way in the first place, but I don't really see the need, at this point, to go out of our way to do it *less* like native, when fixing the tests—which you're not even removing—takes two changed lines.
Why spend a patch on this? I don't think they're necessary, but they aren't really hurting anything.
Because interface checks have to make some sense. What are we testing with IAgileObject for instance?
That it doesn't support IAgileObject? I don't know why Mohamad added those, but I'd guess it's either because he some application query for it, or because all of the dxcore documentation appears to be written in WinRT. Both seem quite plausible and both seem good reasons to check something like this.
I may not test anything this deeply myself, without a preexisting reason, but I really don't think it makes sense to remove tests, or bring our implementation further away from behaviour already tested.