The main concern is about the same public IP to 2 separate interfaces, WAN and L2TP fake bridge. Or I am missing something?
I'm not sure I understand your concern. The public /32 IP will exist on the Mikrotik only once, and you can choose whether you attach it to a dedicated interface (the port-less bridge), to the WAN, or to another interface. If your Mikrotik's WAN was connected to internet directly, you wouldn't need this trick.
The kernel accepts packets for any local IP regardless the interface they came in through, and the IPsec stack responds from the same address to which the initial request of the IKE session has arrived. Connection tracking and the dst-nat rule ensure that the initial request which came in to the private IP of the WAN will be seen as coming to the public IP by the IPsec stack and that the external NAT box will see the responses of the IPsec stack sent from the public IP as coming from the private IP of Mikrotik's WAN. Only for connections initiated locally the source address is chosen depending on the out-interface chosen by routing or, if set, the pref-src of the route. So if your NAT box between the Mikrotik and the internet supports ESP forwarding, you need to make sure that if the first ESP packet is eventually sent by the Mikrotik (I don't remember the L2TP initial exchange), it will be sent from the private IP attached to the WAN or src-nated to it, so that the external NAT box would see it coming from its LAN subnet. And you need to care about this latter point only if there is a chance that clients running on public IPs will connect. As said earlier, if the external NAT box cannot forward ESP, the complex setup for multiple clients behind the same public IP forces a "client-side" NAT into the path and thus eliminates ESP from the scenario even if the client is actually running on a public IP.