If I'm wrong, I will apologize profusely. But I've tested this. I will even accept a punishment if I'm wrong (typos excluded).
I always assumed that the %TriggerValue% (and %TriggerBase%) returned the values for the currently running macro. But I just did some testing and that's not entirely accurate. And that results in a problem. Let me start with an example.
Let's say you have two macros called Macro1 and Macro2, and Macro1 is triggered by the hotkey CMD-A and simply calls Macro2. I.e.,
Both macros will see the following values from these tokens if you trigger Macro1 with CMD-A:
%TriggerBase% = Hot Key Trigger
%TriggerValue% = CMD-A
But if you change the calling macro to pass a parameter like this:
Then Macro2 will see the following values:
%TriggerBase% = Hot Key Trigger
%TriggerValue% = zzz
...and these are now different values from what Macro1 sees.
In other words, TriggerValue can be modified so that it's different in each child macro, but the TriggerBase is always the same. Is that the most desirable behaviour? But wait, that's not all.
Until today I thought that TriggerBase would change when you called a macro. I was wrong. I had expected that calling a macro via the Execute Macro action would change both tokens: TriggerBase (probably to "Execute Macro") and TriggerValue (probably to the parameter or an empty string, but definitely not the value from one of its parent macros and yet it inherits the TriggerValue parameter from its parent.)
Think about that. If Macro2 above called a new macro, Macro3, and Macro3 displayed the contents of %TriggerValue%, it would see the parameters that Macro1 passed to Macro2. It would have no way of knowing that it didn't receive any parameters itself from Macro2! It would inherit the parameters passed from Macro1 to Macro2 unless Macro2 passed different parameters to Macro3.
I can't imagine any scenario in which I would want a macro to be unaware that the %TriggerValue% token it is examining was NOT being passed by its parent but rather some inherited value from a macro three level up. Why would anyone want a macro to be unable to determine if the contents of %TriggerValue% was meant for it or for some parent macro higher up in the chain?
A simple solution might be to empty TriggerValue of its contents when executing the Execute Macro action (and no parameters is being passed). But I'm still not satisfied by the fact that TriggerValue and TriggerBase still wouldn't be matching up with each other. I think the best solution would also be to create a new TriggerBase called "Execute Macro" and also set its value appropriately whenever Execute Macro is called. Then everything would be consistent.