I would filter outbound ARP and permit the entire range of x.x.x.2 through x.x.x.6 as the source. Drop any other source.
You still need proxy arp with the static route solution I mentioned.
The rule for proxy arp is this: For any arp request seen on an interface, if the destination IP address is in the routing table and the route points to any interface OTHER than the one where the ARP was received, then reply to the ARP with your own MAC address.
You have a router with LAN interface = 192.168.1.1/24 (proxy arp enabled), a static route to 192.168.2.0/24 through another router on the LAN 192.168.1.2, and default gateway on interface WAN -> 172.16.1.1
If host 192.168.1.15 on the LAN sends an ARP requesting 192.168.1.55, then the router will not reply, because the destination is reachable but via the LAN interface. The same happens if host 192.168.1.15 then sends an ARP request for 192.168.2.21 - Again the router will not reply because while it does know the route to reach .2.21, and it is not directly on the LAN interface, the next hop IS on the LAN interface, so router1 will not answer this ARP either.
If host 192.168.1.15 then sends an ARP request for 188.8.131.52 - the router WILL answer this ARP request because 184.108.40.206 matches the default route, which goes to another interface (wan) than the one the ARP was received on (lan). If you were to show the ARP table on host 192.168.1.15, it would have router1's MAC address for 192.168.1.1 and 220.127.116.11, it would have router2's MAC address for 192.168.1.2 and 192.168.2.21, and for 192.168.1.55, it would have that host's actual MAC address.
Cisco actually has proxy-arp enabled by default, so it's not an unusual thing.
The reason I gave this static route solution should now be more apparent. If the PPPoE connection is active, then your router will have an Active, Dynamic route x.x.x.3/32 gateway=pppoeX. Since the gateway is a different interface than WAN, if the ISP's router sends an arp for x.x.x.3, then your router will respond with its own MAC address so the ISP knows to send this packet to your Mikrotik.
If the user disconnects, the pppoe interface will deactivate, and the dynamic route will go away. Without the static "backup" route, your Mikrotik would consider x.x.x.3 to be part of x.x.x.0/29 dynamic, connected, gateway=wan-interface. So while the pppoe link is down, the Mikrotik will not answer proxy-arp requests from the ISP router for x.x.x.3
With the backup route configured, even when the user is down, the Mikrotik will have a static route to the host which does not "point to" the wan interface, so it should still answer the ARP requests from the ISP router for x.x.x.3.
Double NAT is going to be an easily-accomplished backup strategy, but I would feel sorry for the user if they are forced into this situation. If you have a dedicated IP address, then it should be on your devcie, you know?