Correct, but even in those cases, the specific order should not matter. For example, you may save a reference or an array of references. Or if none is saved, you can iterate over get_children() and do whatever you want, even if they are dynamic and have auto-generated names. Though, in those cases, the specific index does not matter. Cause if you don't have a name or reference, even having the index is not helpful (since you would also need to know the parent, and if they are dynamic, the index can change on any frame as objects are added or deleted).
I'm not trying to be a jerk but the question still doesn't make any sense to me. I genuinely want to know the answer, even if I'll probably still say it's a weird workflow. I've asked a few times and still don't have any answer to the use case. For example, if a particular node, let's say an enemy sprite is at index 5 or index 17. How does that number provide any useful information? It does not appear to at all. You should access objects by name, or by reference. The name makes sense for key objects like the player or main camera, etc. References would make sense for dynamic objects like spawned enemies or power-ups. But in order to obtain an index (like with get_index()) you need a reference to the object. Which means you already have the object in code, so you can move it, call functions, etc. the index doesn't help. If you don't have the index, then you need to find the object, such as with get_nodes_in_group(), get_children(), etc. In which case you obtain a list with references. Again, you have the references, as above, so you have full access to the objects. The index number does not add any additional functionality. I just honestly don't understand.
