COMPIZ_CONFIG_PROFILE is not actually the name of the profile that gets loaded

Of course, we have to be careful to support Ubuntu, which unfortunately uses COMPIZ_CONFIG_PROFILE=ubuntu and that loads a profile named "unity" for historical reasons.

Questionable as to whether or not this is a bug?

As mentioned in the description - it works exactly the way it is supposed to, but it just overloads something that you don't expect. Having it at the top level is necessary though - we need to be able to have a way to tell compizconfig to use a particular backend and integration configuration along with the profile.

So I think the better change would be to rename the environment variable (eg COMPIZ_CONFIG_CONTEXT) and use COMPIZ_CONFIG_PROFILE to overload the actual profile

I know it's designed that way. But it's the design I am questioning.

I think it's too confusing for everyone to have a separate COMPIZ_CONFIG_CONTEXT and COMPIZ_CONFIG_PROFILE.

Best I can tell, the context (which is what COMPIZ_CONFIG_PROFILE really is right now) is the name of the entry to look up in .config/compiz-1/compizconfig/config. It seems to be designed that way so you don't need multiple variables for COMPIZ_CONFIG_BACKEND, COMPIZ_CONFIG_INTEGRATED, COMPIZ_CONFIG_PLUGIN_LIST_AUTOSORT etc.

But it could be simpler...

What if COMPIZ_CONFIG_PROFILE actually represented the profile and we paid attention to COMPIZ_CONFIG_BACKEND? Then you would have enough information to always find the profile data. Information like integration=false could be stored in the backend as part of the profile itself. Thus if both variables are set you can ignore and live without the ini file.

Storing the integration value in the backend could make sense. The other one is plugin_list_autosort - and the same logic would apply there.