While i really like the idea i see several severe problems that limit this build for every-day usage. Some of which may be solvable.
1) Bandwidth:
The most obvious point. Using a single blue belt for all those assemblers is nowhere near enough to make anything in a reasonabe time frame. The blue belt assembler alone would require a dedicated supply belt just for iron gears.
2) Speed:
Some of the items in your example layout are far too slowly produced with just one assembler. From what i can see as a glance i'd say at least stone bricks, blue circuits and copper wires fall into this category.
3) Delay:
As you're not using crossfeed between assemblers (and crossfeeding everything that would need to be isn't possible in a straight rows setup anyway) you're creating huge lag for recipes that require subcomponent crafting within the facility. E.g. for basic inserter -> fast inserter -> stack inserter each component has to literally go full circle before reaching the next assembler.
Possible solutions:
1,2) Rethink which items are considered raw input items, and which ones are better mass produced in a seperate facility. For example in my own mall i consider yellow inserters, yellow belts and straight-pipes as input items. As they require mass production anyway for science packs, and are needed in large quantities and in several recipes each.
3) Add crossfeeding and reorder the assembler in a way that maximizes possible crossfeeds. E.g. Inserters are best build [Long]<[Basic]>[Fast]>[Stack]>[StackFilter] so that each assembler can directly feed into the next one. Decreasing delay and saving bandwidth on the main input belt.
Additional:
If you rigidly improve the facility for crossfeeding it may become feasible to include a second loop for output only (as output items are rarely required for any of the inputs) running to the player-pick-up-point. Which would save bandwidth on the main input line. Of course a second input loop would be preferrable but that sounds a lot more difficult to implement circuit-wise (but then again...i hear you like a good challenge. So for V2 i expect multi-line requests
).
Further bandwidth savings on the main input may be possible by including a few selected "dumb" input belts running vertical to some of the assemblers for high bandwidth inputs (gears, green circuits, etc).
Finally:
Don't me wrong. I really like the idea. Especially the extremely compact pick-up point with just a few chests =). But when i see an opportunity for optimization i can't just silently walk along
.
