As I suspected, the issue is likely the result of an unsafe use of the “Join Curves” component. As a matter of fact, when I open your file on my local Rhino, I see a result very similar to your screenshots above. The culprits are the following components:
First of all, the order in which the list of output curves will be arranged depends directly on the order in which you connected the two input lists. Instead of connecting several input lists to the same knob, I strongly suggest to use “Merge” components which ensure the order in which merged lists will be sorted:
In your case, however, this will not do the trick. “Join Curves” will try to match the list of input curves in the best way possible, resulting in the least possible amount of resulting curves. I honestly do not know which algorithm is used to do so, and I would not assume that the resulting list of joined curves has a predictable order with respect to the input. In fewer words, this is risky.
Now you could try to implement some logic to the output list to make sure it is ordered according to proximity, in order to sanitize the input of your “Sweep” component. However, in this case you have a better option! You already know that those input curves will match two by two, and you have two lists that are ordered identically: the ideal solution is to graft both input lists before sending them to the “Join Curves” component, and to flatten back the output:

Now to be clear, that only works because both input lists are ordered the same. Also make sure that grafting results in trees with identical structures, or at list the same number of ordered branches.
The grafting operation will result in this fundamental change: instead of sending one list of 2*N curves, you are sending N lists of 2 curves. This has two advantages:
- The branches of the tree are ordered according to both input lists, which is the order you expect in your Sweep component. You can then just flatten the output tree to get the exact list you need.
- Instead of comparing 2N curves with each other ( O(N²) comparisons), you are comparing the corresponding indices of two lists of N elements (O(N) comparisons). From quadratic to linear complexity, just with a graft!
Here is your minimal example attached with said change.
FIXED_gh_minimal_prev.gh (35.4 KB)
Now that seems to work fine on ShapeDiver, but please do apply the same to your full example and let me know if the issue is solved. There might be another similar unsafe operation somewhere else that I overlooked.