Cool man. Thanks!

What is really nice is that I can use ({...}: {user = {b = 3;};}) and it overrides. Which provides a nice API for end users (i.e. not having to use mkForce).

So this partially makes sense. But why didn't having a user config with ({...}: {user = {b = lib.mkForce 3;};}) work before? It should have a really high priority.

Without your fix, does the config.default have... no priority? What was the failure mechanism before the fix?

In reply to @infinisil:matrix.org
Before, config.user and config.default had the same priority. The conflict happened one level above

Finally, you have effectively

{
  out = lib.mkMerge [
    config.default
    config.user
  ];
}

Finally, you have effectively

{
  out = lib.mkMerge [
      { a = 1; b = 2; }
      { b = 3; }
  ];
}

Both of which are without priority, so it recurses into the attrs and conflicts because two bs

I recently stumbled upon similar issue when working on home-manager. https://discourse.nixos.org/t/is-it-possible-to-define-systemd-services-in-a-submodule/39538/5

The idea is that enabling https://nix-community.github.io/home-manager/options.xhtml#opt-programs.bash.enableCompletion should set environment.pathsToLink = [ "/share/bash-completion" ];.

I think that module system is missing an option to pass config options recursively up to all ancestors.