AtkStateSet was basically untouched since his creation, and was working fine. But today I found a implementation trick that I don't like or understand. Publicly AtkStateSet is a GObject without any public attributes or any pointer to a private structure. But the set is internally represented as a 64 bit integer, so on atkstateset.c it defines a new structure AtkRealStateSet, also a Gobject subclass, but adding that attribute. So, on atk_state_set_type it fills the type info using AtkStateSet public definition but using the size of AtkRealStateSet. Then the code is full of castings between both defined objects. This just sounds evil. atk_state_set_new is supposed to return an AtkStateSet object but it is in fact returning a AtkRealStateSet object. So if you do this:
   X = sizeof (AtkStateSet)
   Y = sizeof (atk_state_set_new ())

You will get X!=Y

Luckily enough this has been working for years. Mostly because as I said, this was the case since the beginning.

As I said, I can't think on the real reason for implement AtkStateSet like this. The only vague idea is that this was an alternative way to define the private data of the object, but this doesn't explain why they didn't use the usual private stuff (AFAIK, it was available in the past).

So I propose to remove AtkRealStateSet, and just add a private struct to the Set. We can't add now the pointer to the private struct on the public definition, as it is a API change, but we could do that in the ATK 3.0 definition.

BTW: on bug 649031 Trevor suggests to just kill AtkStateSet, and interact directly with the integer (this is what IA2 does). I prefer to keep AtkStateSet, basically because it seems too low level to me and makes code more legible: add/remove stuff instead of binary operations, a proper place to add methods to compare sets, etc.