Unpredictable result for first/last in aggregate_spatial / reduce_spatial

[m-mohr]

While writing a proposal for reduce_spatial, it came up that I thought about "use cases" which compute a value depending on the order of the values. For example, passing a reducer such as first or last (or median) will not give predictable results depending on how the implementation "collects" the values from the underlying spatial areas/dimensions.

Has someone experiences from implementations how this could be handled and documented gracefully?

For now, I added text to the spec that documents a "naive" approach:

The list of values has an undefined order, therefore processes such as last() and first() that depend on the order of the values will lead to unpredictable results.

That makes it "documented", but not very useful for cases where you don't run e.g. "sort" before. What's your take on this?

[soxofaan]

I don't think this is worth to spend a lot of documentation on to be honest.
There is no intrinsic ordering for the combination of two dimensions (even if each dimension has a intrinsic order). I think it's enough to just warn the user to not assume some arbitrary order. Your proposal "naive" text is fine for me

[m-mohr]

Has been improved a bit in PR #261