OK...
1) this variant class is required because:
The most important part of the framework consists of a map of variants. Actually, a class which holds a map of variants. *ALL* the configurations will be stored in a tree, where the nodes hold these.
2) And it needs to be template-free, because:
I don't want to impose the burden of templates for a simple thing which can be defined with a union of POD (plain-old-data) types and a string.
3) Finally, this belongs in the compiler framework forum, because:
The compiler framework is ALREADY in the SDK. The compiler plugin is based on this framework (see CompilerOptionsBase, CompilerTargetBase classes defined in the SDK)