I'm thinking that it is important for an observer to know how a pivot was moved. So to
nsIAccessiblePivotObserver.onPivotChanged, I would add:
void onPivotChanged(in nsIAccessiblePivot aPivot,
in nsIAccessible aOldAccessible,
in long aOldStart, in long aOldEnd,
in PivotChangedReason aReason);
where PivotMovedReason could be:
PIVOT_CHANGED_REASON_ASSIGNED - the position was set directly (i.e. pivot.position = foo)
PIVOT_CHANGED_REASON_MOVED_NEXT - moveNext()
PIVOT_CHANGED_REASON_MOVED_PREV - movePrevious()
PIVOT_CHANGED_REASON_MOVED_FIRST - moveFirst()
PIVOT_CHANGED_REASON_MOVED_LAST - moveLast()
PIVOT_CHANGED_REASON_MOVED_POINT - movePoint()
That might be too high granularity, really I am just interested in assigned, moved in order and moved to point. But if we are doing this, why not...
nsIAccessibleVirtualCursorChangeEvent would get a new equivalent field as well. maybe
nsIAccessibleVirtualCursorChangeEvent.reason

Another idea might be to provide a move id on a successful move. Kind of like how setTimeout returns a handle. This will make it easier to associate move operations with their subsequent notifiers.
So instead of the move functions returning true or false, they would return unsigned long. 0 on failure or anything else on success.

Created attachment 633688[details][diff][review]
Added reason to pivot change notifications
The presenter may choose to display a cursor movement differently depending on the type of movement. For example, in Android explore by touch emits different events than d-pad navigation.

(In reply to David Bolter [:davidb] from comment #3)
> Can you give me the "killer use case" concrete example?
it seems like this is within reason if you believe using events in the first place is reasonable.