Sorting the pavers was indeed the key insight that makes this work. More on that below.
First though, this post adds refinements including separating the ~60K paver geometry from the GH code, something I wish I had done at the very beginning. That data is now in a separate file that uses Data Output to pass the paver curve geometry to the small piece of code that uses it. The geometry doesn’t need to be re-posted each time the code changes - a Rhino file would work as well.
choi-pavers_2020Aug28a.gh (6.2 MB)
The code that sorts the pavers and creates the gradient is now quite small. It uses Data Input to read the pavers passed from the choi-pavers_2020Aug28a.gh file (which must be opened first).
choi-paver-gradient_2020Aug28a.gh (29.2 KB)
Notice that I added two more Rotate components to restore the pavers and their center points to the original orientation after sorting them.
As to sorting, this image shows the result (using only the first 1000 points because Point List is painfully slow with 60K points!). The sequence starts at the bottom left and proceeds vertically, sorting all the points with the same X value by Y. Then the next X value to the right is sorted by Y, and so on.
The very small value required by Jitter is to minimize the vertical swapping of adjacent pavers in this sorted list. Pretty cool and simpler than I expected! 