I think it is if such Spatial is child of a node tree which parentest is at an enabled viewport scene. http://docs.jmonkeyengine.org/advanced/multiple_camera_views.html
I’ve been traversing parentests til reach GuiNode or RootNode, but that doesnt cover all possibilities with precision.
Technically, given all of the different ways that an app can choose to render something… the only way you know for sure it will be rendered is if it IS rendered.
Spatials can be in different viewports or rendered by a post-processing filter or a custom scene processor.
Really, it’s your app that knows and your app should probably have a better way of managing this if it’s really required. Perhaps it’s time to take a step back, explain the real situation, and let us offer advice on how to restructure things at a meta-level.
Because generally, the best way to “only do this when the spatial is attached” is to do it in the Spatial’s (or better a control’s) update… since that’s only called if it’s attached.
So I guess the spatial could even be rendered directly to a texture (therefore to nothing visible at all), and may be there is no straight forward backtracking for that right?
Not sure but such lazy setup of a spatial (all the backtrackings) could encumber the CPU, and even the memory (all waiting queues whenever the spatial gets actually rendered)?
In the other hand, being able to prepare the spatial only after it is attached to something that will let all it’s updates not fail, couldnt be the source of some rendering delays?
May be instead of completely removing it from top nodes, we could move it to valid but background nodes (identical but CPU light usage, no GPU usage) that would not interfere with the current rendering but would still allow us to do whatever setup we try before hand?
Yes, I am trying to setup things before they are properly connected or really ready (like a order-less configuration), I feel it can be done but at a cost.
The alternative would be to change the order of many things I coded, but I think this is the source of some problems I’ve been having…
A bit more blabering…
So basically, the best would be to really study how everything should be coded in the right order. In the other hand I have the choice of lazy configurations and instantiations leaving me more time to code my project’s ideas.
May be the only critical point would be “do it before it is too late” if I reach a point where lazy setups will break something like creating not easily repairable delays or memory hogs or leaks?
I think I know what is the best, I am just considering/testing if the alternatives are viable.
I understand that a performance critical code shall not be lazied, but everything else may be I guess, and there are a lot of things that are not the critical code, that will sit in the shadows there until they are required (this mean they dont have to run with top performance to continue being useful) 
Well, one thing you can definitely count on… if something is going to be rendered then updateLogicalState() and updateGeometricState() will be called. This is how Lemur does its own lazy initialization.