First of all, you are correct that you can take advantage of the profile flags to help you manage the flow of switching between these profiles. In particular, I use the {PROFILE_AT1}, {PROFILE_AT2}, and {PROFILE_AT3} flags to help identify the version, name, and ID of my profiles.
You can also make use of the profile options for execution, to make each of your profiles execute any command within them if they are switched to, and also the option to execute any command within them when they are switched FROM (to another profile). This can help you establish variable values that may be needed by a "hub" or "main" profile that controls these other profiles.
You can also programmatically detect the profile flags of the profile being switched from and switched to, using {PREVIOUSPROFILE_AT1}, {PREVIOUSPROFILE_AT2}, and {PREVIOUSPROFILE_AT3} - or {NEXTPROFILE_AT1}, {NEXTPROFILE_AT2}, and {NEXTPROFILE_AT3}.
Regardless of any of this, no existing command can be executed unless it is already an active profile, or that profile and its commands are referenced globally in VoiceAttack options (as a Global Profile) or locally from within the Profile Options of the active profile.
I use a "hub" profile myself which I call AVCS CORE, where the actual "game" profiles depend upon that main profile for initialization, common functions, and relative common commands (as they pertain to that game profile and the game it is for). All the 'game' profiles must have the "hub" or "main" profile included through their individual Profile Options menus. This lets them execute an existing command (by name) which is present in that "hub" or "main" profile.
If a "game" profile is switched to, a command executes which checks if the "main" profile exists, and then switches to it to initialize the game profile - that "main" profile reads the {PREVIOUSPROFILE_ATn} flags to identify the "child" game profile and the data to load, and then loads itself, the game profile, and finally switches back to the game profile which executes that initialization command one last time (though this time, with a "MyProfileInitialized" boolean as 'true' thus exiting it when initialized, instead of switching to the "main" profile).
The way you are parsing through all profiles is not at all efficient, and if your logic and flow was more thoughtfully designed, not at all necessary.
Not sure if any of this helps, but it's one way you can use all these tools so that a governing "main" profile can have all the information it needs about the "child" profiles it controls.