What to do with "Rules" now? There are still rules contained ...

[senseOPN]

Thinking again about this, it just feels like a bad idea to define "floating" rules by the number of affected interfaces.

Floating rules need to be a separate group, executed before all other rules - but they should also be possible for just one interface - they just have a generic character.

And on the other hand, regular interface rules should be definable for multiple interface without affecting the sequence.

There are plenty of reasons to allow or block something at a certain points of the rules and being able to do this for more than one interface.

Disallowing this just makes the rules more messy and I need now to add any such rule for each of the required interfaces!

[OPNenthu]

@senseOPN What I meant in my last comment was that there haven't been any cases identified yet where someone needed to be able to have a Floating rule with a single interface in order to accomplish something.  There haven't been any functional breakages reported.

The impact is organizational.  If you have any Floating rules in the legacy UI with a single interface, they will be migrated to the respective interface and come out of Floating.  That could be a minor annoyance if you have related Floating rules that you wanted to keep together.  One of the work-arounds provided is to add a loopback or some dummy interface if you really need to keep a single-interface rule in Floating.

Floating rules need to be a separate group, executed before all other rules

This is still the case as the processing order and rule sequences are consistent:

https://docs.opnsense.org/manual/firewall.html#processing-order
https://docs.opnsense.org/manual/firewall.html#rule-sequence