• Suppose I have a headless machine with link-local connectivity
• That machine has a specially prepared live iso with a well-known (static & link-local) ip address
• The mount point of the store is to be construed at /mnt/nix/...
• Let's call the still anonymous host (no own IP, no crypto identiy) larva
• Now we want to: colmena apply --on larva --over [fe80::47]:2222 --store /mnt/nix

Can you give me a few pointers where to implement this?

What would be the conceptual steps for feature parity with deploy-rs and enable deployment of home-manager profiles as a "grand unified deployment tool"?

I think this interface is not necessary and using the equivalent upstream interfaces would lead to less confusion.

• In a flakes world, the way to determine meta.nixpkgs would be as follows: inputs.colmena.inputs.nixpkgs.follows = "";

It is really a nightmare in terms of composability to have this attribute exposed via meta. I wonder if it would be possible instead to expose it via the normal (composable) module system and shallow evaluate for peek. something like this:

let
  colmenaNixpkgs = {
    options.colmenaNixpkgs = {};
  };
in (nixpkgs.lib.evalModules { modules = [colmenaNixpkgs]; check = false; }).colmenaNixpkgs

I saw your efforts to speed up evaluation. This might be a project that you might keep an eye on: https://github.com/kamadorueda/santiago

Not immediately useful.

• the reason for this change is to have more transparent separation of concern between effectuations of the module system and pre-module system effectuations

• with improved flakes support down the line, pre-module system effectuations will get more complex

• if the code was clean before, this does not introduce a change in behaviour. Unclean prior code, could now be surfaced by this.