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:
