From James:

We don't have public API event that corresponds exactly to state changes in aria-busy, so for now, it's undocumented. The user message in VO that an application is busy comes from other scenarios like a busy process, which is usually a blocking application, so it wouldn't be appropriate to expose that view the rendering engine. Currently we expose the property but not a Notification indicating the state change.

At the UAI TF meeting today, we decided to take out the bulleted list above the table as long as the information is covered either in the table or elsewhere in the document.

The only things that don't seem to be covered are:

aria-hidden: this will affect the visibility state when the object is in the accessibility tree
<als> I know this is tied up with the aria-hidden issues but we don't talk about exposing any states for aria-hidden in the state/property mapping table. Should we have something more there for cases where the object is in the accessibility tree? </als>

aria-multiselectable changes: user agents SHOULD cause the destruction and recreation of a new accessible object for the element, because it is a major change where the interfaces exposed via accessibility APIs change as well.
<als> aria-multiselectable processing will be covered in the section on Selection Events. See Bug 13258 </als>
<als> First, we don't have aria-multiselectable in the events table so we don't specify to fire an event when it changes. Should we? Second, we have a section on selection that talks about the multiselectable property but it does not say anything about what to do if multiselectable changes. Is the above text correct? It seems similar to section 5.8.2. Changes to document content or node visibility. </als>

Closing this one as the remaining actions have been copied to Bug 11514.