If I remember correctly, the advice against config options was exactly against setting options using config.exs/Application.put_env/3 because those are global in your application. Generating customized modules according to “config options” is completely different, because nothing is global: you simply define a module customized for your purposes, and different part of the application can generate different module. I believe that generating different code according to different options is an important feature, and the driver of most of my architecture.
The idea is precisely not to have to pass optional arguments, or even to customize what the default value of the parameter is! This is precisely the case with my PhoenixComponents example. One may want to specify a default width for form fields (i.e., set a default value dynamically at compile-time) and allow the user to override it on a case-by-case example (by making it an optional parameter in the component).
I think we have pretty different opinions fundamental principles of code organization and on the proper role for dynamic AST generations, and that’s ok, but I can’t see how your (admittedly more elegant proposals) can support the dynamic AST generation I need.
