Unless something hurts as much as it’s supposed to, nothing gets done about it.
– John Oliver, August 4, 2019
Data trees are curious things. They require constant attention when building a model. I do this by examining the output of every component along the way, usually with text panels and when necessary (frequently!), using the ‘vuTreeList’ tool I referred you to earlier.
I looked at your code/geometry in your original post in this thread but haven’t looked at any other versions because it’s too much work. The answers below use the simplified model I posted yesterday.
First, this yellow group numbers the perimeter curves. They are the basis for all the data trees that appear along the way, so keep these numbers in mind:
The “guts” of what I added today are in the cyan group (below). Simple, right? 
Shatter uses the same segments from Explode and the ‘t’ (lower case) values from Evaluate Length to split the perimeter curve edges at the “balcony” locations, then Cull Pattern gets every other piece, effectively ignoring the parts where the balconies are located.
The first Join Curves component combines the short Line SDL bits and the line that connects them. Nothing tricky about that but notice that ‘Simplify’ is used on its output. In fact, ‘Simplify’ is used three times in this cyan group, none of them arbitrary, all are required to get the downstream data trees re-aligned. This is very important to understand. Use text panels and toggle ‘Simplify’ to understand why.
The purple group at the bottom generates 14 random integers (one for each perimeter curve) representing the number of floors for each building. But as you might guess, this presents a different problem due to the fact that curves 0, 11 and 12 aren’t separate buildings at all but intended to be “holes” in their surrounding curves (13, 4 and 9 respectively). I didn’t try to solve that problem.
Type_01_2019Aug8a.gh (35.7 KB)