I'm reading through the module system deep dive on nix.dev and am wondering if there is a behavioral difference between setting an options default behavior in the config attribute vs the default attribute in mkOption.

this

{
  pkgs,
  lib,
  config,
  ...
}: {
  options = {
    scripts.output = lib.mkOption {
      type = lib.types.package;
    };
  };
  config = {
    scripts.output = pkgs.writeShellApplication {
      name = "map";
      runtimeInputs = with pkgs; [curl feh];
      text = ''
        ${./map} ${lib.concatStringsSep " "
          config.requestParams} | feh -
      '';
    };
  };
}

vs this

{
  pkgs,
  lib,
  config,
  ...
}: {
  options = {
    scripts.output = lib.mkOption {
      type = lib.types.package;
      default = pkgs.writeShellApplication {
        name = "map";
        runtimeInputs = with pkgs; [curl feh];
        text = ''
          ${./map} ${lib.concatStringsSep " "
            config.requestParams} | feh -
        '';
      };
    };
  };
}

How does the module system handle definitions with no priority?

I've got two modules

{lib, ...}: {
  options = {
    name = lib.mkOption {
      type = lib.types.str;
    };
  };

  config = {
    name = lib.mkDefault "foo";
  };
}

{...}: {
  config = {
    name = "bar";
  };
}

If I evaluate them together, I get "bar" for the value for name. How does it handle this situation? Is is like using mkForce? Does it bypass the priority system completely?

I imagine the answer is somewhere in this function but I am having trouble working through the logic.
https://github.com/hsjobeki/nixpkgs/blob/985fc9b995c07037f6a6273bafa3526f06bb2343/lib/modules.nix#L818

On a side note, this appears to be the place where option declarations with a default attribute value use mkOptionDefault.