[This is preliminary documentation and subject to change.]
For objects that have screen locations, NAVDIR_NEXT and NAVDIR_PREVIOUS should traverse them in an order that the user will consider 'reasonable'. In most cases that means in a left-to-right, top-to-bottom ordering (in English-speaking countries), but in other cases it could be based on front-to-back or proximity or even alphabetical ordering, depending on the nature of the container.
For objects that do not have defined screen locations, the order is entirely up the application and clients should make no assumptions about this ordering. It is acceptable for non-visible objects, such as GROUPING objects or objects that are only temporarily hidden, to be interspersed with visible objects.
Next and Previous should always visit all visible child belonging to the parent object. Each child should be visited only once. A voice input or macro utility should be able to implement generic next and previous commands that obey those restrictions and so are "well behaved" from the user's perspective. Certainly a Next command that got you into an infinite loop while only visiting two objects in the container would not meet the user's expectations.
By extension, Next and Previous should not loop around. They should fail when attempting to move before the first object or after the last object.
The order used by Navigate is not necessarily the indexing order used with Child.