Upon even closer inspection, the sloppy loop wasn't really the problem (it was a problem though, a stupid one at that)!
I was trying to get a layer width by dividing two integers:
VuoReal real = intA / intB;
This worked kind of, as long as intA was an integer. If intA fell below 1 it would just end up in 0s, cascading down the code which made the for loop look like the culprit, putting out the same number for every iteration. Creating a new VuoReal that got the value from the integer input solved it.
I get the easy part, I just don't think it will be that easy ;).
This is a relatively small fixture patch for instance. Totally unusable because of the drawers. I think a build list combined with a single iteration really is a lot more suitable for an application like this (apart from some LTP scenarios). However, if you think about this reversed with a nested list input, I think it can give sort of an idea on how it would be.
If anything, I think a prompt for the index when you connect a list to a single input, or selecting it in the input port window would be better (for this instance of Vuo anyways).
I'm a bit ambivalent regarding the drawers. Noting that the previous feature request mentioned ArtNet/DMX, I've been working on a sane way to get fixtures into Vuo. Listifying 22 inputs makes an absolute mess because of the drawers. I think opening for drawers on outputs will make about the same, or even worse clutter. Especially with lists in lists.
As a suggestion instead, I've made some "breakout boxes" for lists in my list tools (found here: https://vuo.org/node/2184) keeping in line with the select in/out nodes of getting 2 or 8 (and 4 as well). It should be about as easy as a drawer, but a bit more maintainable in terms of composition structure. If needed, larger batches can be gotten, but not sure if it is necessary. There are two versions of the three nodes. One will just pull out the following X number of objects, while the other will be based on index.
I think that if you have a full universe open as a drawer, it is probably not the most efficient method. Using an index at least should be a bit cleaner.