Change:
<ins> # This tests validates the order of generated sections that may contain # other sections. # When a `volume` section has both `subvolume` and `target` children, # `target` must go before `subvolume`. Otherwise, `target` will become # a child of the last `subvolume` instead of `volume`, due to the # order-sensitive config format. # # Issue: https://github.com/NixOS/nixpkgs/issues/195660 import ./make-test-python.nix ({ lib, pkgs, ... }: { name = "btrbk-section-order"; meta.maintainers = with lib.maintainers; [ oxalica ]; nodes.machine = { ... }: { services.btrbk.instances.local = { onCalendar = null; settings = { timestamp_format = "long"; target."ssh://global-target/".ssh_user = "root"; volume."/btrfs" = { snapshot_dir = "/volume-snapshots"; target."ssh://volume-target/".ssh_user = "root"; subvolume."@subvolume" = { snapshot_dir = "/subvolume-snapshots"; target."ssh://subvolume-target/".ssh_user = "root"; }; }; }; }; }; testScript = '' machine.wait_for_unit("basic.target") got = machine.succeed("cat /etc/btrbk/local.conf") expect = """ backend btrfs-progs-sudo timestamp_format long target ssh://global-target/ ssh_user root volume /btrfs snapshot_dir /volume-snapshots target ssh://volume-target/ ssh_user root subvolume @subvolume snapshot_dir /subvolume-snapshots target ssh://subvolume-target/ ssh_user root """.strip() print(got) assert got == expect ''; }) </ins>

Discussion:
in btrbk's example configuration. This information can be found in too. The structure of in the NixOS module should conform to the way that the configuration actually works. In this case, the configuration is an ordered list of pairs, but since Nix does not really have this data type, probably a text block like s elsewhere would be most appropriate. The current attribute should be deprecated. I can make a PR for this if the above changes look appropriate.
are always generated under a section. So any settings inside will actually belong to that volume, according to btrbk's "applying to last volume" behavior. This makes the setting generation is truely order independent, and prevent the footgun of btrbk's handling of configurations. The current impl should prevent but not cause the cross-interaction. Is there any practical bug you have met with the current config generation? No. In module system, options are merged by some implicit order when there is no explicit or . This makes approach have a surprising interaction with other definitions of the same option, contradicting your intention.
there is sorting in place so the order is deterministic: for each nesting level, key value pairs go first and nested attributes go last. this makes the nix -btrbk mapping deterministic and conforming to the note you linked: global values go first.
Thanks for explaining this -- I probably should have taken more time to look the implementation already in place. That being said, I did experience a bug when migrating from a working to the NixOS module (or at least it seems like a bug to me). Under , I have: which generates The above Nix config seems to imply that should be applied to whole not just , but this is, in fact, what the generated config produces. I might be missing something here.
Could it be that is the culprit? is being treated like a subsection, which it is, but it is not subsection like /.
:thinking: So can be both a section and a child of section . I think modifying the sorting order to other options ---could fix it. Generally it's better to make the whole typed. But maybe it would take much effort.
Fixing the sort order would be a good occasion to make it clear in the description of the option.

About making settings typed: did it but it would be better with a free-form module so that we do not need to adapt the module when new options are to btrbk like rfc 42 advises. (note that I didn't know about free-form modules when I rejected this PR)
The issue here is that whether an option is a "section" or "subsection" matters. We need special cases to give them priority, or it would break silently. That may be worse than "need to adapt for new options".
we can have both with a free-form module
Do you have interest to fix the field sorting and maybe port with free-form modules? If no one claims it in 24h, I'll try it tomorrow.