Ah, funny to see that a lot of the subjects touched upon here are questions we also had to think about for Nickel as well. Would be interesting to share some of the ideas and insights on both side. A couple points:

• We have Profpatsch 's approach to defaults and forces: those are just priorities. But in Nickel priorities are builtin, and somehow orthogonal to the value (stored inside metadata), so the interpreter just transparently ignores them. That is, {foo | default = 5}.foo is just 5, without having to care about the priority. To override it, you need to merge it with something else which defines a new value for foo.
• I think that some form of static dependency tracking is important as well. Because scoping is lexical, we mostly use free variables, which seems to be a reasonable over approximation (that is, you can determine statically what fields in the final fixpoint another field depend on). I guess you could even be smarter about record accesses (if you only see options.bar and options.baz, then you can avoid depending on options.whatever and other fields).This also paves the way for incremental evaluation.

merging is different from typechecking
conflating the two is a big source of annoyance

Ah, funny to see that a lot of the subjects touched upon here are questions we also had to think about for Nickel as well. Would be interesting to share some of the ideas and insights on both sides. A couple points:

• We have Profpatsch 's approach to defaults and forces: those are just priorities. But in Nickel priorities are builtin, and somehow orthogonal to the value (stored inside metadata), so the interpreter just transparently ignores them. That is, {foo | default = 5}.foo is just 5, without having to care about the priority. To override it, you need to merge it with something else which defines a new value for foo.
• I think that some form of static dependency tracking is important as well. Because scoping is lexical, we mostly use free variables, which seems to be a reasonable over approximation (that is, you can determine statically what fields in the final fixpoint another field depends on). I guess you could even be smarter about record accesses (if you only see options.bar and options.baz, then you can avoid depending on options.whatever and other fields).This also paves the way for incremental evaluation.

merging is different from typechecking
conflating the two is a big source of annoyance

In reply to @nbp:mozilla.org
Almost the same story for SOS, the intent was to not remove mkDerivation but delay it to be executed at the very end of the fix-point, thus making packages just ordinary attribute sets available through prev/super, which can be overwritten by using Nix's update operator within Nixpkgs' overlays.

by flattening python packages under the top-level fix-point. What these python sets are is a custom python package with a set of python packages relying on these.

To make it short, this is providing only a different scope from which packages are taken from. I opened a PR on this topic a while ago. https://github.com/NixOS/nixpkgs/pull/44196

An alternative would be to make inherited inputs. For example:

{
  python99Packages = {
    __scope = { buildInputs = { python = …; }; }
  };
}

In which case one could assume that the last scope definition overrides the package inputs, unless override by the user with the update operator.

We have many options to choose from.