Item#1 and item#2 are doable as is today in a zone concept for FortiOS. Not if you had a question in those two items but wanted to point that out.
it can no longer have unique policies applied to it because the interface itself can't be referenced for policies
That's the down fall with zones, once you decide on zones you can't do interface filter for a src/dst-intf, but you can still write specific rules
The use of zones doesn't magically prevent you from writing rules that impact traffic from an interface or network level.
How can we allow for the powerful grouping of interfaces without sacrificing the ability to have the occasional unique policy for a single network?
Again, keep in mind traffic is only going to be allowed if you "allow" it. Firewalls don't magically allow all traffic to all interfaces in that zone-group unless you write a policy to allow it.
I'll try to demo what I'm getting at;
zone == INSIDE
members; vlan10, 20, 30 ( networks 10.10.0.0/16 10.20.0.0/16 10.30.0.0/16 )
zone == OUTSIDE
member; wan1 wan2
I could write a very simple policy that allows ALL of those members ;
service http https
# that how a lot of fwadmin write such a rule which could be ideal or very much not, or total bad if some one add a new interface into INSIDE but didn't want that networks associated to existing rules for INSIDE--to--OUTSIDE zone.
If I only wanted to allow 10.20.0.0/16 and not 10.10.x.x or 10.30.x.x, then I would need to adjust the rule to allow that traffic and just only that traffic.
service http https
BOTH encompass the deployment of "zones", one is probably written much better or secured, YMMV but the ideal of zone management is demonstrated.
So determining what you need in rule set is critical , & when designing rules that uses zones and positioning of interfaces in a zone very critical and should be reviewed in depth.
Also to throw this out; vendors like CHKP and Forcepoint has an allowance for both zone and non-zone rules inject or mingled together in the rule-base. These rules allow for broad and fine crafting of traffic flows, but you still need to be careful in rules creations and where you use zones at.
So you can craft rules with src/dst zones; or even src-zone & dst address
or even match statements similar to the following;
( ( src-zone &
( dst-zone &
dst-addr) ) this is what fortios, jnpr,panw...... can already can do btw so this is nothing new here..
I still do not see a clear picture of a grouping of zones and the benefits. Send an FR to sales and see what they say. Most admins are using zones for the 1> wrong reasons or 2> deploying them incorrectly or 3> without a full understanding of the zone concepts, and this based on my 20+ years of observations with zone based firewalls.
So my final answer, everything you mention can be controlled with the degree of a fine-tooth comb or as loose as mane comb for a horse , within the current usage of zones.
You just have to think it out and design the zones to meet the security INF needs.