Caveat: I know nothing about the “Zollinger Pattern”.
However, I can see problems in this model. You have a super complicated way of making grid points that introduces some anomalies, such as rows vs. columns and the sequence of points in each branch. Easily replaced by a single component: SDivide (Divide Surface). Your point grid can be matched by adding Flip Matrix with ‘Reverse’ enabled on the output.
The number of divisions in one direction (5) doesn’t match the number in the other direction (3). Does that matter? (Later: I don’t think so.)
You are connecting the top-right corner of one box with the bottom-left corner in the other box, so naturally a box placed at the center point won’t align with either of them? Easily “fixed”, though maybe that’s a defining characteristic of the “Zollinger Pattern”?
Your don’t need four copies of Construct Domain when one will do.
So having said all that and made changes to simplify your code, I ended up with the same output you already had.
Zollinger_2019Nov27a.gh (19.0 KB)
But it got me wondering about a different approach. I adapted this model from ten days ago:
It creates all the squares in an alternate pattern, evenly spaced. From there, I messed around (for too long now!) trying to get a “Zollinger Pattern”, whatever that is. I need a break so will post this as is, for whatever it’s worth.
Zollinger_2019Nov27b.gh (25.4 KB)
P.S. I can cull unwanted lines by length but 1) that feels tacky and 2) it doesn’t add the missing lines.
Zollinger_2019Nov27c.gh (24.1 KB)
P.P.S. Oh dear, talk about tacky! What’s a “Zollinger Pattern” again? 
Zollinger_2019Nov27d.gh (23.7 KB)
It’s not robust in the sense that the slider in the blue group must be manipulated to choose from available lengths when the number of rows or columns changes. In fact, the ‘size’ slider (box dimensions) or the ‘X size’ or ‘Y Size’ sliders (base surface) can also affect the chosen culling length.