What I'm trying to say is I don't see where native draws such a "big" or hard line between the COM methods?
Yes, it does. This behavior isn’t new and is easy to test. I believe this addresses most of your concerns. I’ll include the test and prepare an MR, we can discuss the details there.
I don't mind a simpler implementation don't get me wrong, but the problem with separate method impls like in your branch is that I can't see how to expand on it to make it more correct in the future. Wouldn't that be a problem?
We’re talking about a few trivial functions, right? So replacing them would not be of much waste. Even if, hypothetically, we wanted something closer to your solution, we could get there incrementally instead of complicating a single change that’s already large.
Yes, the branch is missing synchronization between the legacy attribute set and the standards-compliant one. I can imagine various ways to address that. My preferred approach would be to keep the main code path simple and efficient and avoid relying on tracking every possible place we think may change, and instead find a solution that doesn’t depend on hoping things won’t change behind our backs. That may require listening to more mutation events, I'm not sure.
Note that with this patch, the synchronization issue isn’t visible to scripts (which make up the overwhelming majority of consumers). They will use only one model at a time. It’s only visible when mixing C APIs and even then, only has minor impact if interfaces are used consistently. That makes the issue non-urgent, IMO.
What I like about this solution is that it keeps the code as simple as possible, and its impact is mostly limited to IE9+, the legacy complicated code is barely changed. Since IE9+ aims to be standards-compliant, using the well-proven Gecko implementation seems like a good fit and a safer bet. And if that’s not enough, we can increment on top of that.