Hello @rdovadia
I will do my best to explain what's going on under the covers, but it does involve some things that aren't simple, so bear with the length of this post.
Let's start with talking about Ethernet switches. These have multiple ports and learn which MAC addresses (the unique addresses packets use at this layer) are reachable from which port. The problem is, what happens if instead of building a tree of switches, you build a topology that has a loop in it. For example, maybe you have three switches, and you connect them all to each other in a ring. This loop causes big problems, because now those MAC addresses are reachable via two different ports on each switch, and any broadcast traffic ends up going around and around (and around) forever. This leads to "bad things". So, the networking work invented the Spanning Tree Protocol, which lets these switches talk to each other and discover what the underlying topology is, and it lets each switch decide which port to disable in order to break the loop. Now, you can connect your switches in a loop topology, and some of those connections will just be disabled instead of causing traffic to loop around. To do this, they typically use a prioritzation approach, where one of the switches is higher priority than the others (say, the core switch in a core+edge structure). That bridge won't disable its ports, but the edge switches will disable the ports that connect to each other. This all works well. Edit to add: only smart/managed switches typically implement this protocol.
So, what does this have to do with Nest WiFi Pro? Each Nest WiFi Pro unit has a virtual "switch" implemented in software. On the primary (#1) unit, that switch connects the LAN Ethernet port, the client-facing WiFi ports for each of the 2.4GHz, 5GHz, and 6GHz bands, and another WiFi port for the (hidden) WiFi mesh interconnect running in the 6GHz band (this shares a 6GHz radio with the client-facing 6GHz network, but under the covers, it's a separate interface). On the primary, there's also a virtual interface that is used to connect all of that to the router + firewall.
On the secondary (#2 and #3) units, they are in "bridge" mode, so that virtual switch has all of the above plus the WAN Ethernet port connected to it.
Here's where the problem comes in – that WiFi mesh interconnect hides the entire 802.11s mesh network behind that one (virtual) switch port on each of the Nest WiFi Pro units. So, from a switched network perspective, any packets that go out to the mesh are taking "one" hop to get to their destination, regardless of what the mesh actually does to get them there.
So, now what happens when we connect any of the secondaries via Ethernet. Let's start with the simple (and supported) case: connecting something like #2 directly to #1's LAN Ethernet port. In that case, we have introduced a loop, since traffic could go through either the Ethernet connection or through the WiFi mesh connection. To resolve that, they run the Spanning Tree Protocol on those virtual switches, and have the priorities set such that the Ethernet port has a higher priority than the mesh port and the primary unit (#1) has a higher bridge priority than the secondary unit (#2). The result is: #2 disables the mesh port on its virtual switch. So, all of the traffic from its WiFi clients goes back to #1 through Ethernet. This works really well, and you can put one or more inexpensive unmanaged Ethernet switches in between #1 and #2 (as long as they don't try to participate in the loop detection Spanning Tree Protocol).
But, what happens when you only connect #2 and #3 to each other via Ethernet? We still have a loop between them (that Ethernet connection and the mesh interconnect), and they both have the Ethernet port configured to be a higher priority than the mesh port. But, since they're both secondaries, they have the same bridge priority. So, for this to work properly, we want #3 to disable its mesh port and we want #2 to keep its mesh port enabled. But, from a Spanning Tree perspective, they are peers – STP doesn't know that one of them is further from #1 than the other, and the 802.11s mesh protocol doesn't run over Ethernet. So, maybe, sometimes, STP ends up working the way we want it to. But, if we get it wrong, and #2 disables its mesh port, and #3 keeps its mesh port enabled, the traffic from #2's clients is going on a really bad path (it would go from #2 to #3 via Ethernet, onto the mesh, and from there, depending on how far away #3 is, either directly to #1 – perhaps very slowly – or bouncing back through #2!). The thing is, the spanning tree protocol runs continuously. It may update the tree every few seconds, and it will try to see if the loop has been broken manually by sending probe packets through those disabled switch ports. The result can be that, in the topology you have built, things "flap" back and forth a bit.
Whew. So, that's what's going on, and that's why it really isn't going to be reliable. You really need to either move #1 to a different location or find a way to get it connected to your existing network from where it is.
