In the world of “normal” networking devices, you cannot take a particular VLAN from a member port of one bridge and connect it to another bridge. Only Linux-based networking allows to configure things in such an extraordinary way. And I strongly prefer and recommend to use an extraordinary solution only where the goal cannot be accomplished using an ordinary one.
Yes, I do, I mean a single common bridge for multiple VLANs, some of them playing the roles of WANs and others playing the role of LANs (in general case, here you’ll have a single LAN and a single WAN).
There is no need to visualize a hybrid port in some special way. If the port is colored the same like one of the VLANs, it means that that VLAN passes through that port tagless; if other VLANs are shown to pass through the same port as well, it is a sufficient indication that the port is a hybrid one. Using this approach, a colored port with no other VLANs than the same-colored one is a pure access one, and a port whose color doesn’t match any of the VLANs passing through it (ideally some shade of gray) is a pure trunk one.
Thinking on how to visualize the “redirection” of a VLAN from one bridge to another would have lead you to thinking on what would be necessary to actually implement it.
I wish I was so comfortable with drawing like you are (see this for comparison, it took me hours), but no, the drawing is still not self-explanatory and needs an accompanying text. From the drawing alone it is not clear that the virtual machines run “inside” the Debian server and that VLAN 111 passes through ether3 of 4011 and eth0 of the Debian server. I know I’ve said to concentrate on the logical topology, but this particular moment (eth0<->ether3 connection carrying two VLANs) is critical for grasping the overall scenario. Also describing the links (arrows) with names of interfaces to which just one end of the link is connected may introduce confusion.
Exactly.
This was true many RouterOS versions ago, where you needed one bridge per VLAN to be able to affect membership of ports in VLANs. Before vlan-filtering, all frames were bridged to all other ports of the same bridge, and no tagging/untagging on ingress/egress was possible, it had all to be done using /interface vlan.
Yes, as explained above.
For this exact scenario, correct, you could have the WAN VLAN (111) and the LAN VLAN (1?) on the same bridge even with vlan-filtering=no. But vlan-filtering=yes is also necessary to allow the actual “filtering”, i.e. without it, VLAN111 would be available also at the other Ethernet ports, which is not desired in many cases.