Weird ARP issue on with MultiWAN manager

I have Zyxel NR7101 on IP passthrough mode connected to WAN port of a Bananapi BPI-R3. I am using a not super recent OpenWRT snapshot

OpenWrt SNAPSHOT r24140-1c7fd93fc2 / LuCI Master git-23.266.27574-7744ad0

and MultiWAN:

mwan3 - 2.11.12-1

The wan interface shows:

root@OpenWrt:~# ip a show dev wan
4: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 8e:e3:d4:0a:90:bb brd ff:ff:ff:ff:ff:ff
    inet 193.210.X.X/30 brd 193.210.X.X scope global wan
       valid_lft forever preferred_lft forever
    inet6 fe80::8ce3:d4ff:xxx:xxx/64 scope link
       valid_lft forever preferred_lft forever

Yet, when I ping -I wan the tcpdump shows ARP request sent on WAN interface...

23:54:52.478176 ARP, Request who-has tell 193.210.X.X, length 28
23:54:53.533985 ARP, Request who-has tell 193.210.X.X, length 28
23:54:54.573984 ARP, Request who-has tell 193.210.X.X, length 28
23:54:56.478749 IP 193.210.X.X > ICMP echo request, id 13160, seq 4, length 64
23:54:56.527973 IP > 193.210.X.X: ICMP echo reply, id 13160, seq 4, length 64

Therefore it keeps losing first few packets.

root@OpenWrt:~# ping -I wan
PING ( 56 data bytes
64 bytes from seq=4 ttl=57 time=49.333 ms
64 bytes from seq=5 ttl=57 time=31.324 ms
64 bytes from seq=6 ttl=57 time=41.280 ms
--- ping statistics ---
7 packets transmitted, 3 packets received, 57% packet loss
round-trip min/avg/max = 31.324/40.645/49.333 ms

When the ping starts working there is an entry for the IP in arp table:

root@OpenWrt:~# arp | grep          0x1         0x0         00:00:00:00:00:00     *        wan

I found out that this happens on the secondary interface which is not used.(with higher metric/weight). But if primary goes down and comes back up, it is never assigned as primary because pings fail from the point of MultiWAN.

I found a post pointing that this issue is related to MWAN3.

But it does not really explain exactly due to which configuration system is trying to send an ARP request to an ethernet interface which does not have the correct subnet. Any ideas why this is happening?

There seem to be an issue ticket related to it: