While not an explicit Polyscope Node, you can already achieve this functionality using a combination of Switch/Case and subprogram calls (or script function calls). Let your main program consist entirely of one large switch/case, and let sensors (possibly put in threads) set the switching variable. Each case can contain a single line, a Call Subprogram instruction. The only downside to this method is that subprograms cannot be called from within subprograms. (Not cleanly through Polyscope, anyway. You CAN get around this by calling a subprogram via a script line, and that will work for some reason)
This does not involve any nesting of loops or Ifs, and helps keep the structure organized, as you will be creating the “jumpTo” instructions as their own URP files. So if you needed to touchup “Gripper_Dropoff” or something, you just open that job, make adjustments, save the job, and reload it from within your main program.
The reason you don’t see Goto/Label commands like other languages is because it is not typically safe to assume you can jump around and execute different lines of code, because the robot may be in motion. I have limited experience with other industrial robots, personally, but our main robot technicians here configure programs the same way on them.
Here’s a brief example of what I’m talking about. You can use threads which monitor inputs to act as your jumping criteria instead of programmatically assigning “Robot_Step” sequentially. This is also a nice way of preventing undesired robot moves, as the Switch will only care about the state of “Robot_Step” after it is done executing the subprogram (which likely would end by sending the robot to some Home or Perch position.