First of all, for what you describe (distinct dst-nat rules per public IP), you do not need to create a macvlan interface, it is enough to attach both public addresses to ether1 and simply let some of your dst-nat rules match on dst-address=x.x.50.24 and some on dst-address=x.x.50.25.

You only really need macvlan in more complex scenarios like VRF, where it is indeed necessary that packets that came to a particular address on a physical interface are treated as if they came in via some other interface. There is nothing bad about using a macvlan interface in general, but the ISP may not be ready to handle its made up MAC address, whilst the use of an individual MAC address is the key component of the macvlan concept.

To make it clear whether the ISP has a problem with that unexpected MAC address or not, enable the macvlan interface (during a time when you can ignore the fact that it causes the internet connection to break), run /tool/sniffer/quick ip-address=x.x.50.25 port=4567 and try to open http://x.x.50.25:4567 in a browser on your mobile connected to LTE or 5G network; if the sniffer shows packets to come in, you can probably keep the macvlan in use, otherwise you'll have to move the x.x.50.25/24 to ether1 and try again. But the ISP may still have an issue with outgoing packets with the macvlan MAC address as source, so the above is only a first step check; the next step would be to ping the x.x.50.25 from the phone (which requires an app).

Other than that, you have set use-ip-firewall under /interface bridge settings to yes; I suspect you have done that due to a misunderstanding of the purpose of this setting as I cannot see any need for setting it to yes in the rest of your configuration. Setting use-ip-firewall to yes messes up with NAT quite a lot, so unless you can explain why you need it, set it back to tde default no.

I applied that, and it worked perfectly. Now, if I want to route traffic for bridge1 through x.x.50.24 and traffic for bridge2 through x.x.50.25, is it enough to use routing rules?

I followed your instructions and enabled the MACVLAN interface, but after running the packet sniffer and trying to access http://x.x.50.25:4567 from my mobile device, I didn't see any incoming traffic from MACVLAN interface.

I applied that, and it worked perfectly. Now, if I want to route traffic for bridge1 through x.x.50.24 and traffic for bridge2 through x.x.50.25, is it enough to use routing rules?

You don't need even that - the interface is the same for both addresses, and the gateway is the same as well, so your existing rules in srcnat are sufficient, no need for dedicated routing tables and routing rules. Just replace macvlan1 by ether1 in the second rule and change the action from masquerade to src-nat.

I followed your instructions and enabled the MACVLAN interface, but after running the packet sniffer and trying to access http://x.x.50.25:4567 from my mobile device, I didn't see any incoming traffic from MACVLAN interface.

If you do the same now with xx.xx.50.25 attached to ether1, can you see the TCP packets to port 4567 to come in?

So In this case, just using firewall rules can effectively separate the two subnets from each other?

I can ping x.x.50.25 from outside the LAN.
...
I couldn't see any TCP Packet.. Is this what you meant?

So In this case, just using firewall rules can effectively separate the two subnets from each other?

What exactly you mean by separation of the subnets? You wanted each of the two LAN subnets to be reachable from the internet, and to send its own traffic to the internet, from another public address. This is ensured using the rules in dstnat and srcnat. To isolate the subnets from each other, you have to use firewall filter rules - without them, devices in one LAN subnet will be able to talk to devices in the other one.

Instead of firewall filter rules, you could use VRF for complete isolation of the LAN subnets but a) it would be an overkill and b) it would require the macvlan interface to work.

I can ping x.x.50.25 from outside the LAN.
...
I couldn't see any TCP Packet.. Is this what you meant?

Before, with macvlan active and x.x.50.25 attached to it, could you ping the x.x.50.25 as well? Do you ping from the internet or from the LAN?

If you cannot see any TCP packets even now as the x.x.50.25 is attached to ether1, but the dst-nat rules are working the way you expect, either your ISP filters your incoming traffic or you sniff incorrectly, so maybe you were sniffing incorrectly before as well? Did you press [Start] in the window you have posted? Did you specify the port 4567 in the browser on the phone as I suggested?