Right now you can get the state of a object using atk_object_ref_state_set, and it is defined as a virtual method. The common and sensible implementation is use a incremental approach, so each class redefining this method calls first the parent implementation. In this way, for example, gaillabel redefines ref_state_set to add some states, and "inherint" the states from gailwidget.

But the question is that the base class is AtkObject, that also adds some states, creates a new state set on each ref_state_set call. This makes easier to fill the state set, as the different implementation of ref_state_set doesn't need to check if it is needed to remove states, they just need to add their states knowing that the state_set is newly created.

But this means that you can't add states from outside this implementation, for instance in a container widget that want to add some state to a child state_set. And you found strange situations, as you can notify a state change on this child, but there is no way to include this state on his state_set (this also applies to remove a state).

In my personal case, there are a widget that is a list of items. Those items are generic button-alike, and the list implements the selection of each one. But, as those items are generic, they don't have the information of being selected. So I can't add the state SELECTED on each item implementation because I don't have the information, and I can't add this state on the container due the previous reasons. Although this issue could be solved implementing ATK_SELECTION on this container, I doubt that I could do that , as it is instantiated on javascript code (I still need to investigate this). And anyway, I think that this is problem, no matters if this specific example could be solved in other way.

Although to avoid any change on atk, I could use solutions like g_object_set_data or AtkAttribute, I feel that this solution is a hack.

I think that the solution is that each AtkObject should have a private state_set, so it will return always the same set, as it is done with the relation_set. And in the same way, it is what is done on GailCell, as it overrides ref_state_set without calling atk_object_ref_state_set (as it seems that doesn't require AtkObject sets). We can see this as a "cached" version of the current approach.

But the problem of this is that current GAIL (and cally) ATK implementation is implementing ref_state_set with this "fresh state" in mind, so several changes would be needed to implement this.

Of course, it is possible that I'm missing something, and that this was made in this way by purpose. For example, if we implement this solution each ref_state_set should start to check if it is needed to remove any state from the current state_set. Doing that, you need to take care of not remove states defined outside the ref_state_set implementation. Anyway, I think that this would be unlikely, as I see the capacity of adding states to the state_set just for the states that the object implementation can't manage. 

So lets start debating the problem, and my proposed solution. Opinions?

[1] http://library.gnome.org/devel/atk/stable/AtkObject.html#atk-object-ref-state-set