You are right - they do not communicate their MAC tables to each other. The time a switch learns about a device connected to another switch is when a packet hits *that* switch.

Normally a broadcast will be carried across all switches in the VLAN, so when a PC arps, all switches will hear about it and add it to their tables. If after (by default) 5 mins, no traffic from said device hits the switch, it wll be removed from te table (cam aging).

So, with a simple network of two switches and everything in VLAN1, and three systems - A, B and C. A wants to talk to B. A&B are in switch 1, C in switch 2.

It sends a broadcast (ARP) which gets flooded to B, and via switch 2 and this seen by B. Switch 1 adds A to the address table, as does switch 2 - pointing at the inter switch link.

B unicasts the ARP response to A. Switch 1 adds B to the table and forwards the response to A as A is in the table. This does not get sent to switch 2. A&B talk to each other and the traffic is constrained to switch 1. After 5 mins the entry for A in switch two ages out and is removed.

A then starts to purely stream data to B. B does not bneed to respond. A stays in the table, but after 5 mins, B ages out. At that point, the traffic will be sent to switch 2, and seen by C as no switch knows where B is.

Because of whatever imaginary application is sending all this data, C sends a "quench" message to A. This gets flooded everywhere. the address of C is added to tables. A Acknowledges and responds, but carries on sending the traffic. As B is not in the table, the traffic is still flooded, but my totally imaginary application does somethin useful. It triggers a packet that gets a response from B. That puts B back in the filter table of switch1, and stops the traffic being flooded. If B sends anything o B, it will be flooded on switch 2, including to 1, but on 1 it will be sent only to B. any response to C will then put B in both tables.