Some of the systems that we use during our compilations mandate that we use a Modules package, which dynamically modifies a user's compilation environment. 

We have the potential of executing several module commands prior to building.  If the wrong module is loaded we can end up with inconsistent builds.

Ideally, changes in modules should create a separate build hierarchy. Similar to the behavior of <link>static or <link>shared.

Example of what would be ideal.
<module> purge           #  remove all module
<module> module1      #  load moduel1
<module> module2      #  load module2

  OR perhaps

<module-load> module1 module2 # This can purge all modules and load module1 and module2.
 

I am relatively new to boost so I'm not 100% sure the proper method of implementing something like this or if something like this already exists.  I've looked at the features documentation and it leaves me a bit confused. If I were to use features, it looks like I would have to change  every "compiler".jam file needing this feature.  Is this correct?.  Does anyone have an example of how I can implement something like this?

Here's what I'm understanding from the documentations:

In user-config.jam:
feature module-load : : free propagated ;

import toolset : flags ;
flags gcc.link MODULE_LOAD <module-load> ;
flags gcc.compile MODULE_LOAD <module-load> ;

In gcc.jam   ?????????????
actions link
{
    "module purge"
    "module load "  $(MODULE_LOAD)
     ?????????????
}

actions comile
{
    "module purge"
    "module load "  $(MODULE_LOAD)
     ?????????????
}

Thanks,

Erik