Adding to this conversation. The one benefit to how things are currently being done is that changes to a single section (firewall, policy, conntrack, nat) just requires a simple delete of the entire table, then an atomic load of the updated config.

With this change, that wouldn't work, because a change to one section would then wipe out all other sections, only putting back the single section (e.g. a change to policy would delete nat, conntrack, and policy).

This could be solved easily by just getting a list of existing chains and then iterating over them in the Jinja2 template and deleting them. This would likely necessitate the renaming of some chains so that they can easily be sorted. It could be something like is currently done for the sets:

Example

VYOS_FORWARD_filter would become F_VYOS_FORWARD_filter
PREROUTING would become N_PREROUTING

Most of these changes would be fairly innocuous with the exception of smoketests. Those would need to be upated, since a lot of them are looking for a specific chain name after configuration.