Yes, thanks -- I just had not realized it was asynchronous, though I understand why it is. For me, since what I will do with the data can't be done until it is loaded, a blocking call would have been useful, but I understand the issue with doing that in general. Since this code is likely to be called inside its own thread anyway (ie. a user has clicked on a hotspot or we are in the process of loading a pano) one could generally use a blocking version. But I will rewrite the code to work with a non-blocking version.
Another option that would have solved my problem, by the way, would be if variables passed to loadpano could be used in <include> directives, the same way that variables that are passed from the HTML/javascript can be used in those directives. Or existing variables with "keep" on. It seemed there was no reason not to allow those variables to be used, as they are ready before the xml is parsed, so I was not clear on why loadpano's variables are limited in that way.
However, includexml is a more general solution that I think many can find useful if they want to be able to load data and other XML based on something the user does in a pano, so I like it broadly.