I took a look at one of your description files.
A few things I noticed:
1. You are turning on cameras, and then turning them right back off (with no delay). I don't understand why.
I'm not aware of that situation; can you elaborate?
2. At one point you turn OFF a single camera, with a note that it turns off the other cameras in that group of four. I don't know if that works. I know that if you turn one ON, the other three go off, but I don't know if sending an "off" to one of them turns off all four.
It does... and I believe it is even documented somewhere in the X10 wikis. If a camera power supply (of the type I'm using, at least) receives either an On or Off command on another unit code that is within its bank of four unit codes, it will turn itself off. I have confirmed this via actual testing, and in fact, most of my macros would not produce usable camera operations were it not true.
In any case, this is not relevent to the issue of "confused" macro operation in real-time.
3. You seem to be calling a lot of sub-macros. Why not just put the actions all in one macro? Are those sub-macros also condition based? (that's the only reason I see for sub-macros being called like that).
For details, please refer back to the post where I attached those macro descriptions, but yes, conditional execution is one of the reasons that necessitated calling sub-macros in situations where the "code" would otherwise have been "in-line".
the CM15A can only send one command at a time. So, if you want a sub-macro to run to completion before the main macro continues, then you might want to put a long enough delay into the main macro to accomplish that.
Yup, in fact, there are a couple of places where I've done that. It's not a really viable solution in most cases, though, because it is not really possible to determine how long it will take the sub-macro to run under actual operation, so one has to "pad" the delay, making it quite a bit longer than is normally necessary or desirable - just to ensure that it is long enough under all conditions (which is another aspect that is difficult to determine).
All appearances so far lead me to believe that sub macro "calls" are actually "spawns" (where the sub-macro competes for execution time with the calling macro, rather than suspending the caller until the sub-macro finishes. This would be "OK" if it could be confirmed that it works this way all the time, and if it was understood how the "time sharing" actually occurs... although, there are some cases where it is desirable or necessary to stop the caller while a sub-macro runs, in which case it becomes necessary to "daisy-chain" individual macros, you describe below:
Another way to do it might be to have the main macro end with the execution of the sub-macro. Then, the sub-macro can call the next macro when it finishes.
This would be "OK" -albeit a bit cumbersome-
if calling operations were completely predictable; perhaps they are, but my own observations lead me to suspect they are not. Even so, it may be the only coding option available... and, in fact, it is the reason why you see a lot of my macros calling other macros as their last action.