Is this a bug? Single Interface in Multiple Zones

I'm writing this issue to inquire if L(uci) allowing the setting of a single interface in multiple zones is intended and supported behavior or not.

Say I have the below configuration (stripped to only show forwarding logic):

config defaults
	option forward 'DROP'

config zone
	option name 'wan'
	option forward 'DROP'
	list network 'wan'

config zone
	option name 'lan'
	option forward 'ACCEPT'
	list network 'vlan30'
	list network 'vlan99'

config zone
	option name 'can_access_wan'
	option forward 'DROP'
	list network 'vlan10'
	list network 'vlan99'

config forwarding
	option src 'can_access_wan'
	option dest 'wan'

The nft list ruleset for the above looks like this:

table inet fw4 {
	chain forward {
		type filter hook forward priority filter; policy drop;
		iifname { "br-lan.30", "br-lan.99" } jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
		iifname { "br-lan.10", "br-lan.99" } jump forward_can_access_wan comment "!fw4: Handle can_access_wan IPv4/IPv6 forward traffic"
	}

	chain forward_lan {
		jump accept_to_lan
	}

	chain accept_to_lan {
		oifname { "br-lan.30", "br-lan.99" } counter packets 0 bytes 0 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
	}

	chain accept_to_wan {
		oifname "eth1" counter packets 0 bytes 0 accept comment "!fw4: accept wan IPv4/IPv6 traffic"
	}

	chain forward_can_access_wan {
		jump accept_to_wan comment "!fw4: Accept can_access_wan to wan forwarding"
		jump drop_to_can_access_wan
	}

	chain drop_to_can_access_wan {
		oifname { "br-lan.10", "br-lan.99" } counter packets 0 bytes 0 drop comment "!fw4: drop can_access_wan IPv4/IPv6 traffic"
	}
}

This way the user can create "category" zones, in this instance a "list" of devices that can access the internet. LuCi seems to allow this multizone assignment of a single interface and it seems to work.

However, there are quirks with it e.g. when it comes to "input" "output" "intra-forward" it can lead to unintended misconfiguration as now those interfaces grouped together aren't actually meant to interact in those ways and are now coupled with those rules. I've gotten around this by placing such zones at the VERY bottom with "drop" on all those rules to allow earlier rules in the chain to dictate logical zone coupling. I thought maybe if this is intended to stay and not be limited from the user the Zone could have a selection of "drop | reject | accept | empty" for example, so we can make it not render any nft rules for those at all? Though if it is unintended then should there be a limitation placed on the user, e.g. a check where if it is detected that there is a network/interface in more than one zone then a warning or failure happens?

I hope I explained this well enough, thank you for all your time and efforts to make such an amazing work

Reproduce the configuration in LuCI and inspect the generated nft list ruleset output, focusing on how one interface is assigned to multiple zones and how input, output, and intra-forward rules are coupled. Determine whether this behavior is supported, then define whether completion requires a warning or restriction, or a documented way to suppress unwanted zone rules.