@Buckeye Thank you, this was the most useful kind of report: you built a real site, predicted what would happen, and you were right. All of it is fixed and live. (Took me and a college a while to debug, so nice one!)
Your VLAN assumption was correct. With a site numbered from 110, every port still carried pvid=10 and the trunk still tagged 10,20,30, because those are the module defaults and replacing the site VLAN table never repointed them. With ingress filtering on, those ports sat in a VLAN the bridge did not know, and the bridge VLAN entries had tagged=bridge and no member ports at all. So yes: devices on those ports would have seen each other and nothing else, exactly as you described. Your switch would have been isolated.
For the record on where the fault lies, since it came up earlier in this thread with the multicast rule: this one is entirely ours and entirely new. The single-device switch role has always done it properly, with a VLAN interface on the bridge for the CPU, the bridge tagged in the VLAN table and untagged members per VLAN. It was the multi-device code, a few hours old at the time you tested it, that swapped the VLAN table without touching the port assignment. No MikroTik documentation involved.
Now, on your site:
add bridge=bridge vlan-ids=110 tagged=bridge,sfp1 untagged=ether1,ether2,ether3,ether4,ether5
add bridge=bridge vlan-ids=120 tagged=bridge,sfp1
add address=192.168.110.3/24 interface=vlan110-lan comment="management VLAN"
Three more things came out of chasing yours, all found by tests rather than in production:
- The first fix put access ports on the guest VLAN, because I picked "the first VLAN that is not management". A default that quietly puts every wired port on the guest network is worse than the bug it replaced.
- Trunks were coming out tagged and untagged in the same VLAN entry, which contradicts itself. That one also affected single-device configurations and is fixed there too.
- An access point ended up with no trunk at all, so a guest SSID on a tagged VLAN existed on the bridge with no way off the device. It looks configured and is not.
Management addressing. You did not raise this, but your screenshots led me to it: every non-routing device was keeping the role default of 192.168.88.2, on a site addressed 192.168.200.x and 192.168.110.x. Reachable by coincidence only, and identical on every device. They are now numbered from the site management VLAN, one each.
On the country list. You are right that it was Europe only, and that was an inconsistency rather than a policy: the shared site block borrowed a shorter list than the per-device Wi-Fi section, which already had the United States, Canada and Australia. It is now one list of 39 across both.
To answer what it controls: today, only the wireless regulatory domain, the country= on /interface wifi, /interface wireless and CAPsMAN. Nothing else depends on it, which is why the time zones are a separate field and have always had the American ones.
It is EU-weighted because we are a Dutch company and the defaults are built around European practice, and that is deliberate rather than accidental. It is also going to matter more than Wi-Fi shortly: the country selection is what we intend to hang ISP and IPTV presets on, so that picking the Netherlands offers the KPN and Ziggo specifics, IPTV VLAN tagging included, and other countries can gain the same for their providers. That does not exist yet, so I am flagging it as intent rather than a feature. If it is useful for American providers we would take suggestions on what belongs there.
On the RB260GSP: agreed, and no change planned. It ships with SwOS, the header says so, and as you say the generated configuration is still a useful reference for the VLAN numbering even when you then set it up in SwOS.