ConfigData code smell. Look for the right way to parametrize

https://github.com/pvs043/cMDTBuildLab/blob/master/Deploy/Deploy_MDT_Server_ConfigurationData.psd1
Please help me to learn DSC (and restricted data language) better, different solutions are appreciated.

Personally I’ve found the Configuration module that exports ConvertTo-Metadata and ConvertFrom-Metadata functions
They appear good for me to dynamically change psd1 document content.

It looks like the some code smell is inherent in DSC configurations themselves designed for LCM automation
Please check multiple Ensure = ‘Present’ and so on.

It is surely convenient trade-off for production using compiled MOFs, but seems undesirable for frequently changing Lab configs, where typos may break things.
I am looking for ways to parametrize both DSC Configurations and that sort of ConfigurationData.psd1 mentioned above.

Perhaps the Lab machine host configuration (and also such things as MDT Server config) should avoid LCM automation at all, using Invoke-DscResource and some humanized kind of configuration data.
Any comments?

Partially answering to myself, just to collect ideas
http://stackoverflow.com/questions/25408815/how-to-read-powershell-psd1-files-safely

Apparently some code smell comes from the design of the original module, where there haven’t had separated two kinds of configuration material: the structure of MDT Deployment share and environmental data

But what about “the core” of DSC DSL, which provokes repeating of Ensure = ‘Present’, MDTBuildRoot = $PSMDTBuildRoot, MDTShareRoot = $PSMDTShare and so on.

Any thoughts on it?