The spec currently states here http://w3c.github.io/aria/aria/aria.html#roles

"Roles are element types and authors must not change role values over time or with user actions. Authors wishing to change a role must do so by deleting the associated element and its children and replacing it with a new element with the appropriate role. Typically, platform accessibility APIs do not provide a vehicle to notify assistive technologies of a role value change, and consequently, assistive technologies may not update their cache with the new role attribute value."

... and Core-AAM also states here http://www.w3.org/TR/core-aam-1.1/#mapping_conflicts

"Host languages can have features that have implicit WAI-ARIA semantics corresponding to roles. When a WAI-ARIA role is provided that has a corresponding role in the accessibility API, user agents must use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language."

Which leaves open the possibility (at the very least in HTML) that a document may load with elements that are mapped natively to accessibility roles to which WAI-ARIA roles are added programmatically at a later point (using for example JavaScript) (this is common in practice with the 1.0 version of the specification).

If a platform does not have the ability to override the role once something has been exposed through the accessibility API, then this introduces a timing problem that could lead to incompatibilities across platforms.