The scroll snap 2 spec says that when there are multiple elements that could be scroll-start-targets for a scroll container "user-agents should select the one which comes first in tree order".

Selecting the first element in tree-order seems like a natural way to resolve competition between multiple targets which would be scrolled to in one particular axis but is perhaps not as flexible as might be needed for the 2d case where an author wants to scroll to one item in one axis and another item in the other axis.

An alternative that might be more flexible would be to compute the intersection of the relevant scroll-start-targets in each axis (originally suggested by @flackr ). This could prove useful for the 2d case where an author has a table/grid and wishes to specify a row and a column as the scroll-start-target in the vertical and horizontal axes respectively (which was the main use case for having scroll-start-target set separate inline and block values, though that has since been removed from the spec). User agents could handle the case where none of the scroll-start-targets end up in the scrollport by giving preference to the scroll-start-target that is first in tree order or some other resolution mechanism or simply leave that for the author to avoid.
Since the current scroll-start-target syntax (scroll-start-target: [auto|none]) takes only one value that should apply to both axes, this alternative raises the question of how to associate one scroll-start-target with a particular axis.
I can think of 3 options for associating a scroll-start-target with an axis:

1. Use the scroll-snap-align properties of the scroll-start-targets, first prioritizing the presence of scroll-snap-align and then tree order.
2. Have scroll-start-target accept keywords like 'x', 'y', 'both', 'inline', 'block'.
3. The previously mentioned 2-param syntax, making scroll-start-target a shorthand for scroll-start-target-{x,y,inline,block}.

Perhaps we could adopt the current spec as-is for the moment, i.e. pick the first-in-tree-order target and scroll to it in both axes, and leave more complicated syntax/logic for a future version of the spec?