OK, second service after deleting a totally irrelevant answer - your only way out is to use this dirty trick to translate an auxiliary connect-to address (which is the only relevant thing you can set on the /interface l2tp-client) into a different source address. If it wasn’t for the IPsec encryption of L2TP, you would configure one of the clients to connect to such an auxiliary server address, create a route to that address with one end of the back-to-self IPIP tunnel as a gateway, you’d use dst-nat to fix the dst-address to the real one for “incoming” packets as they emerge from the other end of that tunnel, and add a mangle rule to assign a routing-mark to choose a route through the non-default WAN.
However, with the IPsec it becomes one step more complex, as the peer, identity and policy dynamically created due to setting use-ipsec to yes in the L2TP client config would be the same, which is not what you need. So at first you have to create the IPsec peer, identity and policy for the specially treated client separately, by copying them from the ones dynamically created for the first peer and changing the local-address of the peer and src-address for the policy to the IP of WAN2 while copying. As the remote address is the same for both peers, you’ll need an /ip route rule to force the packets through the other gateway:
/ip route rule add src-address=wan.2.ip.address action=lookup table=via-wan2
/ip route add dst-address=ip.of.l2tp.server gateway=ip.of.wan2.gw routing-mark=via-wan2).
Of course, the second /interface l2tp-client, with connect-to set to the auxiliary address, has to be created with use-ipsec set to no.
As the next step, instead of assigning a routing-mark to the L2TP transport packets which are received at the “outer” (closer to WAN) end of the IPIP tunnel, you src-nat them to the IP of WAN 2, so the manually configured IPsec policy will match them and deliver them via WAN 2.