pfSense

The actions taken by rc.linkup differ depending on whether the interface has a static or no IPv4 and IPv6 IP, and every other case (where either the v4 or v6 type of the interface is dynamic).
https://github.com/pfsense/pfsense/blob/RELENG_2_3/src/etc/rc.linkup#L70

While there are no doubt some edge case reasons for that being the way it is, it's not sensible logic in general. The actions taken should be much closer to the same between them.

The only known problem this causes is with CARP. The interface_bring_down function removes CARP VIPs from the interface. If you have a static v4 and track6 LAN, this makes CARP get into dual master on WAN when the LAN loses link. What should happen is the CARP IP stays in INIT, which increments net.inet.carp.demotion by 240, which makes the secondary take over for the WAN VIPs. What actually happens is it increments demotion by 240, fails over to the secondary, then the VIP is deleted from the LAN on primary so demotion gets a +240 on the primary because the VIP is gone, and the primary takes back over master. Then you have dual master on WAN.

interface_bring_down should never be run on an interface where a CARP VIP resides to avoid this situation. It's questionable whether it's ever actually necessary or desirable when losing link on a NIC.

This is a potentially touchy area for regressions, so it'll need a good deal of review, testing and time to run in snapshots.