Yes, I had also considered these permutations - and others - during my analysis, especially as a result of the 'experimentation' performed in regards to Incorrect (setvalue) trigger behavior in Enketo when used inside repeat groups?
As you note, these permutations apply pretty much to any xform-value-changed event, not just the odk:setgeopoint described here; specifically what is the proscribed behavior when setvalue triggers and targets are at different levels of the XML hierarchy?
I think in regular non-repeating groups, I dont really see much issue or why either the trigger or target need to care, because the XML path to the correct one is wholly deterministic and unique. So I dont think anything special needs to be said for 1 & 2.
Permutation 3 - where the trigger and target are in the same repeat - is the interesting one, and the one I set out to explicitly confirm behavior of because it'll probably be the most common. In this situation I think the expected behavior is that the triggering behaving is kept wholly within the current repeat iteration; that is, that iteration's trigger only affects that iteration's target. This is the behavior I confirmed in Collect but doesnt appear to work in Enketo (see above).
Permutation 4 - where the trigger and target are in different (and non-emcompassing!) repeat is probably something to flag as an error; I have a hard time thinking how deterministic behavior here could be enforced without somehow strictly associating the specifc repeat iterations with each other (which at a minimum would require enforcing the same numer of iterations for each...)
Permutation 5 & 6 are the interesting ones IMO - what do you do when your control's trigger is outside of your repeat; eg does the trigger result in all the repeat interations getting recalculated? I could see potential usecases for both these permutation, although it does still feel somewhat of an edge case.
Note, the other permutation I considered, closely related to 5 & 6 would be a trigger and target within nested repeats of each other. Again, this is definitely and edge case but still something that can be defined nonetheless.
As a first pass, how about ensuring the trigger and target have the same XML parent? That probably handles the majority of the usecases. Then we can extend the scope to perhaps ensure they have a common ancestor and there are no intervening repeating groups?
Again, its worth noting this is not specific to exposing odk:setgeopoint in XLSForm per se, but rather how we should fully define XLSForm triggers/XForm xform-value-changed events in general; specifically, it equally affects our existing setvalue action triggers.