I see as most fundamental design flaw, that config files has
not defined negative answer (CONFIG_xxx=n) as valid and stored
option. This would allow to use config fragments which could
override previously selected defaults and values from system
provided config_def files. The Debian system uses some way
how to combine config fragments already.
Other problem is, that the kconfig should allow export
of options touched by user and config file should hold
classification of value origin
kconfig_default automatic_select default_config user
This would allow fragment export even in future kconfig
based tools run. The internals of kconfig already provide
mechanisms which could be base for such options management.