If you “believe the hype”, ip bridge should magically be understood by the driver. At least as I understand it, you should be able to address each of the switch ports directly, setting up VLAN tagging on each through ethN.1234 notation.
In my (limited, as the device itself is obsolete) experience with a DSA capable driver on a tl-wr941nd v2 (100 MBit/s Marvell 88E6060, which might -or might not- be similar to more modern DSA drivers), you do end up with lan1-4 && wan interfaces (ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan"), which can be tagged or bridged as needed - all the magic of configuring the switch fabric accordingly happens behind the curtain (by the DSA module).
ought to share input from the Turris Omnia developer team
The true is that swconfig is no longer available so switch sections in /etc/config/network are obsolete and they no longer work. On the other hand there is no feature lost. VLANs work and are even easier to configure than before.
The difference between swconfig and DSA is that in case of swconfig you have to configure both sides. You have to configure switch using swconfig including port to CPU and you have to configure CPU interface to switch. This is no longer required. DSA manages switch for you. You now have lan interfaces “exported” to CPU and you can bridge them to create separate lan. Tagging is as easy as tagging CPU port. In Luci you just name port lan0.1 and given interface will be tagged 1. You no longer have to manage and tag CPU<->switch ports. Also note that no traffic is forwarded to CPU unless you assign address to bridge. Setting protocol none allows you to create vlan that does not go to CPU at all. If you want to have some port dedicated to specific interface then it is as easy as using that lan interface as any other ethernet interface.
But why do you need VID3 in this case, as it is untagged it will only be valid inside the switch itself. I agree that you found differences between swconfig and DSA, I simply do not yet understand why these actually should matter? If you could state a use case in which the hidden VID3 is important I would love to hear it.
It is considered good practice to move traffic off the default VLAN where possible, in order to minimise the extent to which an unconfigured switch port would give access to the network.
This does not mean that a network which uses the default VLAN is necessarily insecure, and vacating it may not be feasible since some devices have functions that are hardwired to a VID of 1. However, if you have the opportunity to use a different VLAN then that is usually preferable.
And another reason is VLAN filtering which provides for less cluttered topology
Lastly - there is quite a number of users with such scenario (specific VID with untag state) for whatever their (different) use case is, if you were reckoning me being the sole one.
Hope that otherwise we could stay on topic and not debating whether mine or someone else's use case justifies this thread topic in the first place.
a use case basic example for untag 802.1q frames, br-lan enslaving lan0,lan1,lan2
bridge v a dev br-lan self vid 2 untagged pvid
bridge v a dev lan0 vid 2 untagged pvid
bridge v a dev lan1 vid 2 untagged pvid
bridge v a dev lan2 vid 2 untagged pvid
sysctl -w /sys/class/net/br-lan/bridge/vlan_filtering=1
sysctl -w sets the filter in motion and thus to be last or else access to the node could be cut off.