Originally, Vyatta introduced firewall groups for firewall policies only. VyOS inherited this, but over time groups became a shared resource used by NAT, load-balancing, and policy based routing. Keeping them under firewall now causes confusion and unnecessary coupling.

Creating a dedicated, lets call it - set group - subsystem makes sense both architecturally and semantically. It reflects the true, shared nature of groups. The existing set firewall group path should and all its children must be migrated to the new path.

This change establishes groups as a core, reusable subsystem rather than a firewall-specific construct.

address-group nesting was introduced during the VyOS 1.4 development cycle to work around a structural limitation: several subsystems, such as NAT and load-balancing, only accepted a single group reference rather than multiple. Nesting allowed users to indirectly combine groups by including one group inside another.

While functional, this approach added complexity. Nested groups complicate dependency resolution, increase validation overhead, and risk recursive loops. They also make it less clear which addresses are actually applied at runtime, especially in debugging and API inspection.

The cleaner and more maintainable solution is to replace this pattern with explicit multi-group support using the <multi/> XML attribute. Subsystems can then directly reference multiple address-groups, which are merged internally into a deduplicated address set - preserving behavior but simplifying the configuration model.

For VyOS 1.5, the goal should be to deprecate and remove group nesting. VyOS 1.4 should retain it for backward compatibility.

• set group address-group <name> address <x.x.x.x>
• set group domain-group ...
• set group dynamic-group ...
• set group interface-group ...
• set group ipv6-address-group ...
• set group ipv6-prefix-group ...
• set group mac-group ...
• set group prefix-group ...
• set group port-group ...
• set group remote-group ...