The trouble is that all product manuals (not just Mikrotik ones) usually assume that the user is familiar with the generic features of the protocol and only needs an explanation how to configure the particular product to use these features, while all users assume that the product manual will explain what to configure without need to know anything at all about the underlying protocol.
The more complex the protocol, the more deployment variants exist, so a how-to for each of them could easily mean tens or hundreds of them.
So regarding your questions 1 and 2:
- to traverse a NAT, you need that the transport protocol supports the idea of ports, which you can understand as an extension of IP address, and that NAT devices understand that protocol. The absence of the idea of a port in GRE, L2TP, or ESP means that any NAT device can, at best, provide a pinhole to a single device at the private side at a time.
- specifically for IPsec, tunnel mode must be used because otherwise IPsec includes the IP header into the authentified part of the packet, so as soon as NAT changes it, the packet does not pass the authenticity test at receiving side.
While IKEv1 did not address this, the NAT-T extension to it does - it uses UDP as a transport for ESP if NAT traversal is necessary and a couple of methods to identify the need. IKEv2 uses the same techniques but as part of its specification rather than a separately standardized extension.
So for a road warrior, it would seem that you must use "pure IPsec" as you call it because use of L2TP prevents two road warriors behind the same NAT from establishing connection to the same remote server. If you do so, you must use the "tunnel mode", and it is irrelevant from the NAT point of view whether you choose IKEv1 with NAT support enabled or IKEv2.
However, the "L2TP/IPsec" mode actually means "use L2TP's authentication (which is performed using UDP port 1701) to negotiate keys, and then use IPSec in NAT-T mode (which also implies tunnel mode) to transport L2TP between the peers". So the L2TP is encapsulated into ESP which itself is encapsulated into UDP which can traverse NAT, so this mode can also be used for a road warrior scenario. The advantage is that you don't need to deal with policies, proposals etc. The disadvantage is that you can set almost nothing about IPSec parameters, the checkmark "use IPSec" in L2TP interface settings sets up everything the way it needs it.
As for RSA public/private key authentication, it is not suitable for road warrior setup. The point is that a RSA key pair is individual for each machine, but the peer identification does not support the idea of trying several matching configured peers one by one until one of them passes the RSA key authentication. With peers at public addresses, this is not an issue as you can identify each peer by its public address, but all peers behind an unknown-in-advance public address, which is usually the case with NAT, match the same configured peer at "server" side. But you can use certificate authentication for road warriors if you do not configure a particular certificate for the peer they match to; in this case, any certificate provided by a client is checked for being signed by a certification authority trusted by the checking peer (the server), so any certificate signed by that CA matches. But certificate mode is incompatible with L2TP/IPSec so "pure IPSec" has to be used.
Regardless what "group authentication" method (i.e. shared secret or certificate check) you use to accept or reject the incoming connection request in "pure IPSec" mode, if you need to provide individual settings for a road warrior peer, you have to use the x-auth configuration or its IKEv2 functional equivalent to do so.
I think most of the above can be understood from the manual page
, but I admit it is much easier if you know how IPsec works.