Ok, so I went around the moon again with this thinking it would change and ended up in the same place. Below, I've outlined what's been done, why it's been done the way it has been and show why doing this is not an easy (good) idea.
What it is...
VoiceAttack uses GUIDs to uniquely identify commands. To execute a subcommand, you pick a command from a list (or, choose a command by typing its name... I'll save that for later). The, 'execute another command' action maintains its reference by id because the referenced command can be changed over and over. I think pretty much everybody gets this, so I'll move on.
Why it is...
In the very beginning, the id was unique to the created command, and stayed with the command even on export. What happened was commands got exported, changed up a bit and then reimported with the same ids. An, 'execute another command' action that retains a reference to that command via id now doesn't know what command to execute because now there are multiple commands with the same id. This immediately caused problems, so, what had to happen to keep everything working was that when commands were exported, everything that gets exported had to have a new id.
The problems...
Profile1 has 2 commands: A and B. Very simple: A executes subcommand B when it is called. B is set up by reference (not by name)
Profile2 also has 2 commands: X and B. Very simple as well.. X executes subcommand B when it is called. B is also set up by reference (not by name).
Possible solution 1:
Copy A from Profile1 to Profile2. Subcommands MUST come as a package, due to identifiers.
Warn user: Profile 2 has a conflict: B exists in both places. Do you want to overwrite B?
User selects, 'Yes'
B is overwritten with a new id in Profile2. In Profile2, A can execute B. X can no longer execute B because B's id is now different. We could go another step and assume that we are keeping the same Id, but we may find out that B was actually just NAMED the same and contained totally different actions.
Possible solution 2 (mostly the same as 1):
Copy A from Profile1 to Profile2. Subcommands MUST come as a package, due to identifiers.
Warn user: Profile 2 has a conflict: B exists in both places. Do you want to rename B with, '-1'?
User selects, 'Yes'
B is copied as, 'B-1' with a new id in Profile2. In Profile2, A can execute B-1. X execute B.
There is now B and B-1, both are really the same command.
User needs to fix references or live with duplicated commands.
There are other scenarios... these are just 2 that make this a deal breaker.
What's been done to help:
VA now allows you to copy commands that execute subcommands if the subcommands are executed by name (and not by reference).
The solution for complex profiles:
Switch to executing subcommands by name instead of by reference.
Again, I've dug this one out a couple of times before, and each time I think I'll come up with a way that will ease the process, but it doesn't.