TrackClusterMatch is cluster-order dependent

[wdconinc]

This is actually a logic bug in TrackClusterMatch. The way we implement the matching, the ordering of the clusters that are passed to the algorithm results affects which matches are made. For each cluster the best matching track is picked. That track is then not available anymore, even if it matches better to a later cluster. In this branch, where we potentially change the order of the clusters, there will now be different matches.

So, yeah, this is expected given the code we have, and it likely needs to be fixed so we don't depend on arbitrary ordering of clusters. We should find the overall best matching, not use greedy matching based on cluster ordering.

Originally posted by @wdconinc in #2493 (comment)