If I then import nixpkgs with those overlays, in that order, backtrace overrides autoslot, and I can’t access the latter any more.
Note that I’m using final.python310.pkgs.callPackage and not new.callPackage, for example, because I’ve split up the first and second functions (final and prev and new and old) into separate functions, as they share code with other, similar functions.
All of nixpkgs runs on fix and extends underneath it all, so the fixed points file you want to understand in its entirety.
Customization uses those fixed points to implement callPackage and makeOverridable which are the ones to focus on there.
Try using fix and extends to implement something like a resolver or crawler to get a feeling for how it works without the complexity of packages and derivations. A practical one for you might be “use fetchurl to recursively lookup dependencies for a package” some registry like pip perhaps. This will show how fix and extends solve an otherwise complex problem. You could solve this with recursion and merging attrsets, but you would perform a lot of redundant fetches or write a DFS toposort which is a mess. When this usage clicks for you, the way that callPackage behaves will probably be demystified.
It should also force you to understand how to control overrides vs overlays which differ in discreet ways. The “controlling layers” approach you mentioned is done with overlays, but knowing how overrides fit into the picture is important. Knowing “when to use each” is at bottom what I’m hoping you get out of the exercise.