Blueprint setup hacking:bp-entity-list ordering:bug? pebcak?

[golfmiketango]

I have been totally stuck on my mod for a bit because I couldn't figure out why rails could not go into blueprints with my modded entities added. More accurately, the rails did go in, but at deployment time, the rails would simply disappear as if they'd never been there in the first place. For ages (well, like three days) I was convinced -- due in part to the lack of super-idiot-proof documentation on the finer details -- that this was related to the grid bit shift business. That may be, or may not, but it turns out that reordering entities plays a necessary role in the bug/behavior.

TLDR: My mod injects intangible items into literally every tile of the blueprint. If I inject my intangible items at the end of the list, the right thing happens more-or-less*, but if I inject them at the beginning of the list, the wrong thing happens entirely: specifically, rail ghosts are never created upon blueprint placement.

So my questions are:

• Am I doing it wrong? When hacking on the contents of a blueprint during setup, via LiaItemStack:set_blueprint_entities, are there some rules I should be following about what order the items appear in the array? For example, maybe there are certain entities which occupy magical array index positions and moving them to different indexes would break the blueprint .... hopefully not, but it's an example of the type of rule I mean.
• Is it a bug? Specifically, should changing the ordering of the items ever prevent certain types of items (only rails afaik, but I didn't test much else) from getting their corresponding entity-ghosts placed when the resulting fully-setup blueprint is placed? Which I guess is the same as asking: is blueprint entity ordering supposed to be side-effect-free by design?

In case it matters, when I did this I renumbered the entity_number properties embedded in the table values to match the keys before calling set_blueprint_entities. Presumably that's the right way to do it, if it's valid to do at all.

It's notable that the behavior survives blueprint export and reimport, suggesting it's a magic fully-configured blueprint-entity order, not a magic blueprint-setup-gui entity-order, that I'm observing.

(*) There are some visual glitches in the presentation of entity positioning in the setup GUI. I have a vague hunch about what may be going on there, but I think it's just a gui bug and probably an orthogonal red-herring wrt this bug/behavior. I will report it, but actually, answers to the above will help make that bug report less convoluted.