OK. Now your log shows the following:
09:48:20 ipsec IPsec-SA established: ESP/Transport X.X.X.X[500]->Y.Y.Y.Y[500] spi=0x2ce69f9
09:48:20 ipsec IPsec-SA established: ESP/Transport Y.Y.Y.Y[500]->X.X.X.X[500] spi=0x6633617e
… 35 seconds silence …
09:48:55 ipsec purged IPsec-SA proto_id=ESP spi=0x6633617e
09:48:55 ipsec purged IPsec-SA proto_id=ESP spi=0x2ce69f9
Hence establishment of the IPsec layer has been successful but a) either the L2TP didn’t negotiate properly or b) it was unable to negotiate properly because the communication did not get through.
So a bit of theory: if there is no NAT between the IPsec peers, the control communication between them uses UDP port 500 at both peers, and the actual payload is transported using a dedicated protocol called ESP (or another one called AH, doesn’t matter here). But ESP doesn’t have the notion of a “port”, hence it cannot be NATed. So while establishing the control connection, the peers check for presence of NAT at both ends and if detected at either (or both), they switch over to using port UDP 4500 for both the control communication and the transport - in this mode, the ESP is encapsulated into UDP prior to sending, and the control (IKE) packets are distinguished from the transport (ESP) packets coming in the same UDP flow by means of a distinictive field at the beginning of the UDP’s payload.
Why I mention this is that when you look at log from the working case (Android), you can see that the log shows that this NAT-traversal mode has been chosen:
10:13:43 ipsec IPsec-SA established: ESP/Transport X.X.X.X[32774]->Y.Y.Y.Y[4500] spi=0x8718e8c
10:13:43 ipsec IPsec-SA established: ESP/Transport Y.Y.Y.Y[4500]->X.X.X.X[32774] spi=0xaaf563c
In the same log, you can also see 10:13:44 l2tp,info first L2TP UDP packet received from X.X.X.X, which suggests that L2TP events are being logged. Since an equivalent message is missing in the log from Windows after augmenting the encryption-algorithm list, I conclude that variant b) above is the reason why it doesn’t work. And the root cause is that the ESP packets are only sent if they have a payload to carry, so the Tik acting as L2TP server does not send them until it needs to transport a response to a received L2TP initial packet, and thus it does not drill a pinhole for the ESP packets coming from the remote peer in its firewall.
So check your /ip firewall filter rules in chain=input, and right before the rule permitting incoming connections to UDP ports 500 and 4500, add another rule permitting incoming connections using protocol ESP:
/ip firewall filter add chain=input protocol=ipsec-esp action=accept place-before=[find chain=input dst-port~“4500”].
If you don’t plan to ever connect peers having their own public IP (i.e. without a NAT at their end) in the real deployment, i.e. if you only connect them while testing the setup at home, you can also skip this step and try to connect the Win10 machine and the Linux machine from behind a NAT.