Instead of starting from scratch, I adapted your code:
Point colors (from ColorBa) show each branch.
The only difference between your code and what I had in mind is the Polar component. I would have sorted each branch along a circle. Turns out they do the same thing, as you can see by connecting AlongCrv (orange group) to Pt in the cyan group.
Here is solution with iterative approach. I would usually use C# component, but for this solution I use Anemone LoopâŠ
Peeling_20240105-RG.gh (50.9 KB)
âRound To Decimal Placeâ can be done in standard GH with an expression; I used âround(x,3)â twice on the âKâ inputs to Sort. Looks good 
Iâm a little disappointed that point #47 (the last one) is not the highest point? But it seems to me that iteration can be the best method for this. 
What a problem - I thank you, sincerely, for all these contributions. Not only have I learned tons of things, but I also realize how âimpossibleâ this thing is, as Inno had commented from the start.
While Iâve held off on replying with both my impressions and gratitudes, Iâve spent an obscene amount of time in front of the screen since I posted, parsing together these methods into something comprehensive that achieves the most optimal âorange peelâ connectivity.
Furthermore, as this leads to real fabrication in the shop, by someone else, the order of these points must facilitate walking around the fabricated object (the faceted brep), easily identifying labels (0 to 47) at their locations (edge midpoints), where another 48 parts will match said labels and become appended to the object. Blah, blahâŠSome âbouncinessâ between points is ok, however abrupt turns or spans where a point is being skipped is what Iâm trying to avoid.
Extra:
A big âculpritâ here is the fact that both the first and last set of 5 points are to (preferably) remain co-planar on the bottom and top brep faces respectively, while the rest of the points must eventually link ânicelyâ in between the bottom and top sets. Perhaps I should have mentioned that at the beginning? My guess was that it would complicate the topic description(s) as one of these two sets might have to give in and âsacrificeâ a point.
So Iâm imagining the âspiralâ must be used for the sorting of the 38 points between the 5 on the base and the 5 at top.
Thereâs a lot I can elaborate on regarding each reply/method shared above, as Iâm still borrowing from them (for instance, the âZ bucketsâ, from @sonderskovmathias, is elegant and very useful, itâs getting me close, however the domain divisions get complicated and Iâm thinking I need to partition the points upon sorting them by their Z coordinates so I can more effectively âwalkâ from the first 5 to the next 5âŠ) but I will delay that for when I get to something worth talking about, meanwhile thanks for giving me invaluable options:
Regarding one of the current attempts, borrowing from Matthiasâs Z bucket idea:
buckypuzzle_peel-sorting_1-5-24.gh (38.0 KB)
This appears to be sort along circle within each âZ bucketâ (branch) with the possibility of choosing any pair of adjacent points (by shifting the list of points in each branch) as the start / end for connecting to the next / previous branch (Z bucket)?
Short answer, yes - sorted from polar angles, which I think is pretty much the same as sorting along circles, but I obsessed with aligning all Z bucket/layer planes, not sure itâs the best idea or necessary - anyway, when connecting adjacent end points as you foresee, it almost seems like the order of a couple of these sets needs to be reversed - maybe the point order is rotated or shifted every other Z level so that the end point of the a set below connects to the start of the next above
Interesting thread!
I have the feeling that an automatic result can be achieved with diffuse reaction + vectors⊠making each midpoint a constant source of element âBâ and finding a setup of feed/kill ratio that prevent dead endsâŠ
OR
Something related to this
This is a tool, not a general solution. It depends on a panel of manually entered âPoint Bucketsâ (cyan group). It has features to 1) choose the start point by rotating a plane (teal group) and 2) to shift the list of points in each bucket for optimal alignment of connections to other branches (orange group).
The white group on the right shows connecting lines between each branch (bucket) as pipes, colored white for valid links on the surface of the polyhedron, or red for invalid links.
There are clearly multiple valid solutions depending on the âPoint Bucketsâ, the start point and the shift values in the orange group. Food for thought.
NOTE: The topmost point is in a branch by itself.
@Joseph_Oster I just checked this and itâs very good - It makes a lot of sense (for this case) to swap the âZ-bucketsâ (using/testing domains) idea for your new âPoint bucketâ method.
Sweet.
Itâs similar to the list partitioning I was testing, however with the ability to shift the points and rotate the âsortingâ plane I get very good candidates.
Iâm studying/testing the file now to integrate into the bigger script.
**Apologies for not specifying the bottom/top preferences/requirements earlier. I can see how this changed the approach(es) everyone could have taken.
I will report back with new details as soon as I can!
Best, and thanks again.
Thank you @maje90 for your insight(s).
Given the way itâs made (âliveâ C# component), I cannot use it with the rest of the {larger} script as it will compromise performance/workflow; I played with it, though. Itâs super cool and I see how I could have used it more. In fact, that thread was useful for an earlier (separate) stage of my project.
Thank you
Another useful feature to test for validity is that the âpeel-likeâ path (polyline) should not have any segments that go clockwise (the opposite direction). I havenât used it yet but this is a list of polar angles for each point. Connecting segments between branches should always end at points with larger polar angles then their starting points, eh? Not quite that simple though⊠
Guys,
Iâve gotten to a new place (I think) using Galapagos!
Not that anyone cares, but I am eager to show how you guys have contributed.
I will, later this evening, when I am back from school.
Thank you and cheers!
Alright, pardon the delay.
Part 1.
First things first, hereâs a sample file using Mathiasâ Z buckets method plus Galapagos:
buckypuzzle_peel-sorting-unconstrained.gh (54.3 KB)
For this exercise I used a different brep because mine is too irregular and requires constraints (bottom/top points stay co-planar) prior to specifying a fitness function. I used Galapagos to improve the âaspectâ of the connectivity between points because the default connections can end up a bit too jagged.
Some rules/goals include:
For my required brep (actual project), rules are pretty much the same with the main difference that instead of using the Z layers (buckets) I use manually-entered point sets, as shown by Joseph - this condition can benefit more from the simulated annealing solver option, I think? (instead of the evolutionary solver option) in Galapagos given thereâs a âroughâ solution already in the form of the preestablished constraints and limited number of âintermediate point bucketsâ.
Sharing more of that one in part 2 of this reply.
Havenât looked at your code yet but meant to say earlier that âmanually-entered point setsâ can just as easily be accomplished by manually entered Z values for the âbucketsâ.
Agree - in fact it was better for my case to simply establish the âflowâ of the connectivity via the point sets, or Z buckets, same difference - then align + rotate fitted planes (instead of shifting points, this helped with avoiding lines ending up inside brep and the clockwise turn) at each of these âZ layersâ to limit jumps and create less options because my brep and amount/position of points will not change - however I did want a more applicable solution for a larger point set where the mentioned constraints arenât required.
Made an attemptâŠ
⊠still no idea what this will be used for 
@maje90,
Thanks for taking a look - I appreciate it.
I failed to see the whole thing because I donât have anemone (also trying not to rely on a plugin, however Iâve understood why the loop method has been brought up a couple times in the thread).
Anyway,
youâre right Iâve never elaborated on this thinking it wasnât necessary - as mentioned earlier on this thread, this is for a steel structure of the coronavirus.
The brep is at the core of the entire thing:
The brep edge midpoints are the perfect candidates to enumerate each one of these pieces because from each one of these points, a ârodâ comes out to hold/identify the piece:
