ok, i admit, i did not read all the docs. but still it is kind of annoying/disappointing.

i had a "bit" complex L2 setup with pre 6.41 configuration solely utilising switch chip features on crs1xx/2xx devices.
now the time has come to upgrade some of them to the new style config, which I did. the crs1xx upgrades were time-wise fast, whereas the crs2xx took their time to do the job - alas it is i guess because of the slower CPU.

the box booted, i instantly vent to the bridge menu to check out the converted configuration, and it was empty. no VLANs, no PVIDs, nothing whatsoever.
the previously enslaved switch ports were put into a new interface called bridge1 and the routeros VLAN interfaces were moved from the former "master port" to the newly created bridge.

checking out the bridge forwarding database (hosts print) i saw all the MAC addresses there, but no VLAN IDs. but somehow it was still working, like halfway. so i decided to manually enter all the rules from the former config in the new style, i modified the "access" ports to have PVID set up correctly, and created VLANs in /interface bridge vlan with tagged and untagged entries accordingly. re-checked the fwd table, it looked the same.

then i noticed the "VLAN filtering" knob is not enabled for this bridge, so i enabled it. instantly all the entries were updated with proper VLAN IDs, but as result, my old 1xx/2xx chips were cutting over to CPU forwarding, essentially halving the fwd performance. but remember, i wasn't looking for "not forwarding VLANs on ports they are not allowed on", cause this is what "vlan filtering" means to me. so i turned it off, and performance got better, all according to the docs I knew.

still i was confused, why the damn thing could work at all - as it seemed switching is done based on MAC addresses only (SVL mode) instead of VLAN based (IVL) mode.

so i went on continuing the BAU stuff - provisioned new VLANs on a port all according to the new style config. but it did not work at all. The MAC addresses were learned, but it did not forward no frames on the ports in one direction. then i went over to the former /interface ethernet switch section by mistake - i just had the usual combo in my fingers to check the unicast forwarding base, and i was shocked to find all my previous config there. ingress-vlan-translation, egress-vlan-tagging, the clumsy old style switch VLAN config, etc.
and indeed the changes i made at /interface bridge level weren't here. i got totally confused. As last resort i did the modifications in the old style way here _in_addition_ to the new style config, and boom, it started to work.

long story short:
if upgrading switches of crs1xx/2xx family, the new style config is seemingly just for port assignment. the very same features, that the switch chip does support, are not there at bridge level, so it seems you have to still mess around with the old style config if you are into VLANs and switching. i found the following line in the docs: The rest of RouterOS Switch features remain untouched in usual menus.

come on, why? all this basic level VLAN stuff can be easily translated to switch level configuration. you set up the VLANs on bridge level, and the same structure is generated at switch level.
also, VLAN filtering =/= per VLAN MAC-learning. altogether it is totally pointless to have the /interface bridge vlan menus in non crs3xx devices, as sw bridging is clearly no alternative for those devices.

at least there should be some indication in the wiki to "not to try this at home". or some nice indication - like it is with CAPSMAN managed wireless interfaces, misconfigured DHCP servers, etc - that the VLANs you set up in the bridge section of any non CRS3xx device do not apply until XZ is enabled.

this way you have quite a lot frustration on the user side, and potentially disconnected configuration.