Hi Adam,
You have demonstrated a good understanding of GH to get this far. I am fascinated by the project and keep looking at it, learning more and more about what you have done in this script. I decided though that before giving you more advice about how to keep code simple, I should first address the sweep problem that caused you to start this thread. Unfortunately, when I work on that in depth by focusing on just one of the four “arms”, my brain soon gags on the needless complexity of the GH code.
When I see code patterns like this, and there are many of them, my brain freezes. In part because it’s so difficult to modify one thing without affecting many unrelated things and in part because I know that whatever I do for one branch of the data tree must be repeated manually four times.
Another irritation, though not so much of a show stopper, is the many labeled groups that spread the code out on the canvas. This requires frequent moving of the canvas to see where wires are coming from instead of a complete logical block on one screen. An old rule of thumb in programming is that functions should be no larger than what can be seen without scrolling. Also, when zoomed in enough to work in GH, this sprawl covers the entire screen with groups, making it impossible to right-click on the canvas. Fortunately, double-click to search and the mouse scroll button still work on groups, offering the same options as right-click, but habits are hard to break.
Two more issues related to that last paragraph when groups when groups cover the screen:
-
You can’t click anywhere to deselect all without selecting a group.
-
Alignment of components is more difficult because you can’t start a selection rectangle outside of the group; each component to be aligned must be selected separately. That’s a deal breaker! 
End of rant, back to work… Aargh! I cobbled a fix using that C# sweep thing you had, setting ‘List Access’ on the ‘shape’ input so it handles a list of sections. At first I saw some bizarre results that I managed to filter out, leaving what you want. Later, after clustering it and replacing all four copies of Sweep 1 with it, I noticed that alternate rows were missing geometry. 
Spent a long time looking for why… Found that two sets of rails had their start points opposite of what was expected so applied Flip Curve to them, with no apparent effect. Finally discovered that it was the garbage cleanup I had added inside the cluster that was responsible for removing alternate branches (as originally intended to remove the erroneous artifacts coming from C#).
Looked again and found there was no garbage anymore! But two rows were tapered in the wrong direction, starting small at the column end and ending large. So removed the flip curves I had added, cleaned out my diagnostic bits and got this:
Inside the cSwp1 cluster: (I moved Cape Holes inside it)
Structure_2023Feb11b.gh (85.1 KB)
It’s still a sprawling mess by my standards but I touched as little as possible, for now.
Cheers
P.S.
https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_Brep_CreateFromSweepSegmented_2.htm
) from them. One thing led to another and I ended up with substantially new code. I was very careful to match your V2 results by baking V2 and comparing my new V3 to it. It’s way easier for me to understand, though you might recoil at the tightly bunched code. It won’t look good if you ‘Draw Full Names’ so please don’t.