I didn't attend the talk, but Nix's dockerTools doesn't need to worry about layer ordering because there is no chance of a layer overwriting another (most layers just write to their respective /nix/store/hash-pkgname directories, which is guaranteed to be unique by Nix).

You're right! All layers except the topmost layer consist of non-overlapping store paths. It's not one-path-per-layer as there's a hard limit on number of layers, so we smush the packages "deeper" in the dependency tree together within a single layer. There was some work recently where you could specify which paths should correspond to which layers but I can't recall the exact function.

You do have the ability to add a "customisation" layer on top of your image in case you want to create some directories or run arbitrary modifications which does end up as an extra layer which _can_ override the previous layers hence it's always the topmost. But you usually don't need it.

Source: I did a large-ish refactor to the `buildLayeredImage` functions a couple of years ago. My contribution was adding a `streamLayeredImage` function where you can "stream" a derivation to a Docker image on-the-fly without copying any files/layers in the disk.

Arbitrary can still be deterministic

Nix puts images together in a way that there shouldn't be any overwriting, only additions. If your layers are all additions without any overwriting then the order would be unimportant.

There could be some edge cases I'm not aware of, but from what I know, it should be all additions.