This is something I think that ROS should not allow you to do, at least not without a dire warning.
Specifically, ROS should not allow you to:
- Create a vlan interface on bridge and have the vlan-id of the vlan interface be the same as the pvid of the bridge.
- Set the pvid of the bridge to the same vlan as an existing vlan interface under the bridge.
Allowing both tagged vlan1 and native vlan 1 on the same trunk creates a situation where there are multiple representations (framing) for the same vlan on the trunk link. And that causes problems, and these problems are hard to troubleshoot without wireshark, and not possible to actually tap what's on the "virtual trunk" between the router block and the virtual switch. This is discussed some in the Bridge PVID topic, I am sure other places, but that's the one I found.
Unless you use something like macvlan (similar to a secondary L2 mac address for a ethenet port), all vlans under a parent interface will use the parent's mac address. When ROS vlan-filtering is active, my understanding is that the bridge maintains separate mac address tables for each vlan (Independent VLAN learning (IVL) vs Shared VLAN Learning (SVL)). Because of this, I question your "explanation" of how cached arp was involved.
ROS shouldn't allow adding an ip address from the same subnet to two different interfaces (at least without VRF). Do both interfaces (bridge with pvid=1 with ip address 1.1.1.1/24 and vlan1 with vlan-id=1 with address 1.1.1.2/24) think they are in the same subnet? Did ROS really allow that? Were there connected routes for 1.1.1.0/24 on both bridge and vlan1? I can't think of a good use case for allowing the two interfaces to have ip addresses in the same subnet. Perhaps someone can provide a good use case. I think that ROS should should at least warn the user when they attempt to do this.