Hi again, got a bit more feedback for you.

I was intrigued by your use of LuaEntity::active and exactly how that property works (or doesn't work) on different kinds of buildings. First of all, it's apparently deprecated and "disabled_by_script" is the new property to use (which is the boolean opposite of "active").

Any neighbouring inserters pointing into the disabled building do not care at all, and they'll gladly fill up chests. So setting the slot limit on chests would solve that problem.

Splitters are also particularly troublesome as they'll let items pass right through them. I'm not sure how best to handle them, perhaps turn them into a ghost during configuration and revive on GUI close. But if you did that, why not a ghost for every entity?

I used .active even though it's deprecated partially because that's how it's been done for the longest time and also because writing to it is allowed regardless of whether an entity is updatable or not. It still works for the time being, though I imagine it'll be removed in 2.1 which would require a manual update to the mod anyway. I'll probably change it before then, it was just easier to write in the moment as that's what I was used to. I know, boo hoo one boolean check, but hey, it's probably fine.

I don't think the chest-filling issue is as simple to solve as it sounds. In order to set the inventory limit to something else after placement, one would have to first clear the inventory limit done by the mod, then set their own. This defeats the purpose of having an inventory limit in the first place, since the inventory limit has to be unset one way or another. The "perfect" solution would be to temporarily disable the inserters interacting with said chest/building, much like the mod does already for the placed one. I may end up doing that, though I am trying to keep this mod as relatively simple as I can for the most part.

I did think about using ghosts, since 2.0 allows you to edit their settings it seems perfect for this use case as nothing can interact with them besides the player. As far as I know though, there's no way to actually prevent ghosts from being built by bots, which seems like it would create more problems than it solves. I don't want the player to be rushed to set up the entity correctly before a bot comes and builds it, or force them to think about their personal bots before building anything. Also, you can still place ghosts yourself, you don't need a mod to open it for you automatically, and you can still use the "copy place" feature this mod adds after configuring your own ghost.

I don't think this mod will ever completely solve the problem of "thing automatically starts working in some capacity when I build it", some things (like splitters) aren't designed to stop, and for things like that I'm inclined to say that you'll just have to do the old fashioned "place it somewhere else and then cut + paste it" or "place it sideways/backwards, configure it, and then rotate it".

As far as I know though, there's no way to actually prevent ghosts from being built by bots

Oops, I realised this about 5 minutes after posting. Stupid robots!

I have another silly idea which probably won't work. Construction Approvals stops ghosts from being built by placing a doppelganger ghost on the "enemy" force on top of the original, then removes it when the "approval" is made.

EDIT: I remembered that wrong, it re-assigns the ghost force to a "mutually friendly" force. It seems like the mod has a number of implementation quirks, which fortunately wouldn't apply to this mod.