I find understanding exactly what follow profile does is headache provoking, but here’s what I got;
In the case where follow is used with no parameter…
Switch mySwitch "blurb" { channel="some:thing:channel" }
First, the ordinary OH linkage -
When Item mySwitch gets a state update, nothing (ordinarily) happens to some:thing channel (there are always exception bindings 
)
When Item mySwitch gets a command, it gets passed to some:thing channel, to binding, and usually to device.
When some data arrives from device via binding to some:thing channel, it causes an Item state update.
It is possible to add a second channel to an Item
Switch mySwitch "blurb" { channel="some:thing:channel", channel="other:thing:channel" }
Here things work much the same as the ordinary way -
When Item mySwitch gets a state update, nothing (ordinarily) happens to either channel.
When Item mySwitch gets a command, it gets passed both to some:thing channel, to binding, to device, AND to other:thing channel, to other binding and device.
When some data arrives from device via binding to some:thing channel OR to other:thing channel, it causes an Item state update.
Okay, let’s apply follow profile to channel two
Switch mySwitch "blurb" { channel="some:thing:channel", channel="other:thing:channel" [profile="follow"] }
Here things work differently. The follow profile effectively reverses what the associated channel does, “follow” listens for state updates on the Item and converts them into commands on the channel, and at the same time blocks incoming updates from getting to the Item.
Let’s work it out -
When Item mySwitch gets a state update, nothing happens to some:thing channel. But other:thing channel gets the new state as a command, it’ll get sent to a real device likely. This is the “follow”.
When Item mySwitch gets a command, it gets passed to some:thing channel, to binding, to device. I’m not really sure what happens to other:thing channel, but I think nothing. But note that most likely the command will cause a state update to this Item one way or another, and then follow will kick into action.
When some data arrives from device via binding to some:thing channel it causes an Item state update. This update will invoke follow as already described, and we’ll send a command via other:thing channel
When some data arrives from device via binding to other:thing channel, nothing happens to this Item.
This explains a pair of cross-linked devices behaviour, where as in this case both accept commands and respond with update.
command -> device A (ignored by B)
or
someone presses the button on device A
A updates -> Item A, triggers ‘follow’ to make command -> device B
B updates -> Item B, triggers ‘follow’ to command -> device A
A updates -> Item A, triggers ‘follow’ to command -> device B
This happens because follow profile is too dim witted not to send a command if something is already in the desired state, and the device always responds with an update even if already in desired state.
I’m pretty sure follow kicks in for any update, and not just changes, but stand to be corrected on that.
The cure is a rule to add the needed intelligence.
Now, don’t ask me what follow profile does when you give it an Item as a parameter !!