In my case, yes, the OpenGL context is current on the thread calling Scene.renderUnto with contextDropAndReclaimOnDrawEnabled set to false.
Yes, but it's a bad idea. Making the OpenGL thread current on another thread might not be supported.
Yes, rather queue your task and make the OpenGL context current just before executing your own stuff if necessary. No, no other thread is spawned, look at the source code, I don't create a thread to achieve that. When you use the queue with contextDropAndReclaimOnDrawEnabled set to true, I assume it's almost necessary to make the context current but at least you're on the right thread.
The use of laptops is just an excuse, it can't be a valid reason to do that. Your code can work but it depends on how you use the frame handler. If Node.onDraw() is called elsewhere, it won't be enough. I'm accustomed with this kind of demand in scientific visualization, it's more a source of problems than a solution. If you really want to avoid drawing when nothing changes, draw the scene into a frame buffer object and use this FBO when there is nothing to update. This approach is much better when compositing, especially when using OpenGL in the GUI. Moreover, as you probably use AWT or Swing, some repaint is repeatedly performed anyway.
There is no such issue in efficient "reactive" frameworks that give the illusion of continuously repainting but optimize each sub rendering task to do the costly work only when it's necessary. Repainting on demand and continuous repainting are both supported but the former is more cumbersome and error prone.