It's passed as a script parameter. The ShowMenu function takes four parameters, the last of which is the callback script. You *could*, in theory, pass an actual script variable as that parameter. For example, if you have a script attribute on your game object called "menuhandler", you could call ShowMenu with:
ShowMenu("Some menu", options, false, game.menuhandler)
But when it's the last parameter, the script can be directly inlined:
ShowMenu("Some menu", options, false) {
// inline script commands
}
At the point an option is chosen, the script is simply invoked with Invoke, passing the "result" as a parameter. No other parameters as passed, and all the variables set at the time ShowMenu is called are no longer valid. So you just get the result.
I wrote a simple closure library that allows you to specify variables to be active when a callback is made. I've occasionally thought whenever these ShowMenu questions come up of making a ShowMenu that takes a closure instead of a callback script. Then you could have any variables you wanted passed through. It's more work to set up, but it would be more flexible. (It would be great if all the Quest functions could take a closure instead of a callback! You can't even call an object method with the current scheme, which means you can't pass any state whatsoever without storing it globally. ShowMenu does that itself to hold onto the menu context.)