For the record, I’ve managed to click a proper combination of checkmarks in the “current user” certificate selection strategy form after all so Windows stopped complaining about inability to choose a certificate and have sent the initial request to Mikrotik. But it has taken me just a single step ahead as in that request, the peer ID was the IP address of the machine - ID_IPV4_ADDR which ROS 6.44.3 allows to set as my-id but not as remote-id. And the certificate was even not there because in the EAP workflow, the initiator’s certificate is only used at latter stage, when the channel to RADIUS is established via the responder. So even when I’ve set remote-id to ignore, I’ve still got an error in the sense “identity could not be found” (because in that case, Mikrotik ignores the IDi parameter but expects the certificate to be present in the message).
Specially for L2TP over IPsec, the EAP handling of client authentification is more complex than for IKEv2: the authentification using user name and password is limited to the L2TP layer, while the authorization (without identification) is provided by the pre-shared key and limited to the IPsec layer; if machine certificates are used along with username and password, the mutual authentification of the server and the client machine using certificates is limited to IPsec layer as well. But with user certificates, there has to be an interaction between the L2TP layer and the IPsec layer at responder/server side, which is a complication which principially doesn’t exist with IKEv2.
And given that there is no practical advantage in use of L2TP over IKE (v1) as compared to IKEv2 (the L2 bridging mode of L2TP is maybe supported on Linux but not on Windows or iOS), plus IKEv2 doesn’t suffer from the annoying issue with handling multiple L2TP/IPsec clients behind the same public IP, I’ll not be surprised if support of EAP for L2TP/IKE(v1) will come much later than for IKEv2, if at all.