Let’s stop at this one alone. You use three distinct identifiers - bridgeWLAN, bridge**-**WLAN, and bridgeWLAN-11 in the “new config”. Supposing bridge-WLAN (with the dash) is a typo and it should have read bridgeWLAN, it means that you have declared the router-facing port of the virtual switch to be a tagged one for VLAN 11, so you cannot attach the IP configuration directly to the bridge-facing interface of the router. Specifying pvid=11 for the bridge only makes tagless ingress frames get tagged with VID 11, and only does so unless frame-types is set to admit-only-vlan-tagged - with that setting, the pvid value is ignored. For egress, setting pvid to 11 only causes frames tagged with VID 11 to get untagged if you don’t override that by placing the router-facing port of the bridge to the tagged list under /interface bridge vlan, which is what you’ve done.
So if you want it like this, i.e. the router-facing port of the bridge behaving as a trunk one for VLAN 11 in both directions, you have to attach an /interface vlan with vlan-id=11 to bridgeWLAN (the bridge-facing interface of the router) and attach the IP configuration to it.
For an explanation what “virtual switch”, “router-facing port of a bridge” and “bridge-facing interface of a router” mean, have a look here.
Same mistake here as described above. You’ve put ether5-vlan11-12-99 to the tagged list for vlan-ids=99 and at the same time set pvid for ether5-vlan11-12-99 to 99 under /interface bridge port, so for VLAN 99, it behaves as trunk for egress and as an access port for ingress because ingress-filtering is set to no.
As for why VLANs 11 and 12 do not work - I can’t see anything wrong in what you’ve posted, these should be handled in trunk mode in both directions at ether5-vlan11-12-99. But as VLAN 99 does work, there may be some unusual configuration on whatever is connected to that port from outside, making VLAN 99 pass through in both directions.
Regarding placing wlan1 and wlan2 to the VLAN lists manually, I’m afraid it’s not necessary and maybe it even breaks something. CAPsMAN creates one virtual wireless interface for each SSID and creates the appropriate configuration in /interface bridge port and /interface bridge vlan dynamically.
You cannot. If you connect both the EoIP tunnels to the same bridge, and connect both wireless interfaces to it, the only way to tell the bridge to only allow traffic between eoip1 and wlan1, and between eoip2 and wlan2, would be a complex set of /interface bridge filter rules. But since the membership of wlan1 and wlan2 in the bridge is dynamically created under control of CAPsMAN, and the interfaces are created dynamically, the bridge filter rules would get brooken each time the CAPsMAN configuration would change.
But most important, I still can’t see the point in using two EoIP tunnels between the devices if you can use a single EoIP tunnel with VLANs (supposing that there is no L2-transparent network between the devices).