What I like to do in situations like this – whether I’m using logic nodes or not – is to have two lists.
One list contains the permanent objects, while the other list contains the temporal ones.
From a software-design standpoint, these two different things usually wind up playing by very different rules, and I don’t want the logic to be “littered” with special cases. I’ll have as many different sets of logic … and, different container lists … as I may need to have. And: “everything(!) on this list works this way, while everything(!) on that list works that way, and so on.”
Yes, you might need to look on more than one list. So what.
Depending on what kind of thing you’re talking about, you know which list (“container”) contains it.
If the item can’t be removed, the container “knows the rule,” and won’t let you do it.
The items, themselves, really don’t know or care "how you managed to find them." They could be in more than one kind of container, for all they know or care (which they don’t).
The computer really won’t care either way. But, my design … and “as the years(!) go by” … will.
(P.S. You can completely ignore concerns of “overhead.” Modern hardware runs extremely fast, and the designers of both Haxe and Armory know exactly what they’re doing.)