this uses the existing infrastructure to keep track of the attributes in a collection (and so, associate DISPIDs for them, etc), since it also matches native (same DISPID broken behavior when removing attrs) and we already have the code for it.
While I don't think we need full compatibility with legacy-in-compat attributes right now, we do know that the collection exposes different sets of attributes depending on how it's queried. That means we'd need two separate sets to handle it. Your patch replaces the existing set instead. IMO, the straightforward solution would be to use Gecko for the compat set and leave the existing architecture for the legacy mess.
Overall, the patch feels like a mix of various approaches. For example, the name `find_attr_in_list_by_nsattr` doesn’t make sense, it refers to a “list” from the “elem”, but `elem` is an unused argument now. More importantly, the refactoring doesn't add clear value at this stage and just makes things more complicated than they need to be.
I still don't see why we can't start with just thin wrapper for the collection, so I gave it a try myself. What do you think about something like this? https://gitlab.winehq.org/jacek/wine/-/commits/html-attr