Is it possible?

Probably yes, but it can possibly conflict with the other vpn, if it's the "route everything elsewhere" kind. If I remember correctly, it adds some dynamic rules, so maybe it's necessary to work around that in some way.

Definitely yes, but without seeing the IPsec part, it is impossible to tell you what exactly overrides your policy routing setup. Most likely the IP address assigned to the PPTP tunnel matches to an IPsec policy, but it is not the only possibility. See my automatic signature below for further steps.

It's doable: viewtopic.php?t=169273

My configurations:

1. only the initial packet of each connection is handled by the /ip firewall nat rules, and the resulting handling is stored in the context of that connection in the connection tracking module, so that subsequent packets belonging to that connection could be handled accordingly (e.g. in case of src-nat, subsequent downstream packets are src-nated and upstream packets are un-src-nated symmetrically).
2. if no route at all is available in the routing table indicated by the routing-mark value, that packet is normally routed using routing table main; to prevent that, you need to use an /ip route rule
3. you can configure the /ip ipsec mode-config row not only to let the dynamically created action=src-nat rule match on a src-address-list but also to let it match on a connection-mark value, including the reserved one of no-mark.

i cannot ping my sxt connected to ether2 of my mikrotik on site while i am connected l2tpvpn to the mikrotik.

Wow, what an amount of creativity wasted (I have in mind the script moving your static masquerade rule before the one dynamically created by IPsec).

you'll replace the action=masquerade dst-address-list=excluded-addresses rule in nat/srcnat by an action=mark-connection new-connection-mark=avoid-ipsec dst-address-list=excluded-addresses rule in nat/prerouting and/or nat/output and retire the scheduled script.

Thanks for the nice explanation
...
I made another scheduler for chain=srcnat PPTP_YD to keep it at #=1
...
I didn't change the action=masquerade dst-address-list=excluded-addresses cause I didn't understand this part completely.

when the IPSec is down PPTP is not connecting (if connected it will got terminating) when the "IPSec is killing ike2 SA" before it's get a "new ike2 SA (I)" for about 120 seconds PPTP is just trying to connect and if you remember I had a "IPsec-SA expired before finishing rekey" problem before you told me on another topic to set /ip ipsec proposal to pfs-group=none and it's fixed that "IPsec-SA expired before finishing rekey" problem but still there is "IPSec is killing ike2 SA" and I got a feeling this is a server configuration problem (Linux Ubuntu StrongSwan).

2. Is this normal to having "IPSec is killing ike2 SA"? It's not very frequent though it's like at three days once or every other day.

This means the explanation may have been nice but actually it wasn't clear enough. So again.

If there is no rule in mangle/output (my way) or in nat/srcnat (your previous way) that would exempt the PPTP transport packets sent by the Mikrotik itself from being src-nated to match the dynamically generated IPsec policy, it means that the PPTP transport packets to the remote PPTP server are sent via the IPsec policy. So when the Security Association (SA) linked to that policy is down, but the policy itself still exists, the PPTP transport packets get nowhere, as the policy diverts them but cannot actually deliver them.

It indeed looks like some incompatibility between the initiator and the responder, or maybe it indicates a huge data loss causing the rekey procedure to fail, ot maybe it's the refresh of the "control SA" (the one the peers use to negotiate and control establishment of the SAs carrying the payload) that fails. To say more, I would have to see the logs from both peers, including about 5 minutes before the "killing ike2 SA" messages appear in the log.

if the dynamically added one is at top (#=0) then the PPTP one is not working in order to make that work I have to move it on top of that. Am I missing something?

I will try to clean and setup everything on the server side again to see if it's going to fix it.

/ip firewall mangle
add chain=prerouting connection-state=new action=jump jump-target=mark-connections-prerouting
add chain=prerouting connection-mark=PPTP_YD_GAMING50 action=mark-routing new-routing-mark=PPTP_YD_GAMING50 passthrough=no

add chain=mark-connections-prerouting dst-address-list=excluded-addresses action=mark-connection new-connection-mark=avoid-ipsec passthrough=yes comment="for excluded-addresses bypassing the IPsec IKEV2 OVH20"
add chain=mark-connections-prerouting src-address=192.168.11.94 connection-mark=no-mark action=mark-connection new-connection-mark=PPTP_YD_GAMING50 passthrough=yes comment=PPTP_YD_GAMING50

In your rules, the jump-target in the first rule is mark-connections-prerouting, whereas the last two rules are in chain mark-connections. Unify that one way or the other. Currently, both functionalities that depend on connection-mark should not work as no connection marks are assigned due to this difference.

Is the action=fasttrack-connection rule in filter disabled?

So what does /ip firewall mangle print chain=output say?

/ip firewall mangle
add action=mark-connection chain=output dst-address-list=excluded-addresses new-connection-mark=avoid-ipsec passthrough=yes

add action=mark-connection chain=output dst-address-list=excluded-addresses new-connection-mark=\
    avoid-ipsec passthrough=yes
add action=jump chain=prerouting connection-state=new jump-target=mark-connections-prerouting
add action=mark-routing chain=prerouting connection-mark=PPTP_YD_GAMING50 new-routing-mark=\
    PPTP_YD_GAMING50 passthrough=no src-address=192.168.11.94
add action=mark-connection chain=mark-connections-prerouting comment=\
    "for excluded-addresses bypassing the IPsec IKEV2 OVH20" dst-address-list=excluded-addresses \
    new-connection-mark=avoid-ipsec passthrough=yes
add action=mark-connection chain=mark-connections-prerouting comment=PPTP_YD_GAMING50 connection-mark=\
    no-mark new-connection-mark=PPTP_YD_GAMING50 passthrough=yes src-address=192.168.11.94

So once you add the mangle/output rule above and establish both the PPTP and the IPsec, I'd like to see the output of
/ip firewall connection print detail where dst-address~"ip.of.the.pptp.server"

Then, while pinging 9.9.9.9 from 192.168.11.95, run another command:
/ip firewall connection print detail where src-address~"192.168.11.94" dst-address~"9.9.9.9"

add action=mark-connection chain=output dst-address-list=excluded-addresses new-connection-mark=\
    avoid-ipsec passthrough=yes
add action=jump chain=prerouting connection-state=new jump-target=mark-connections-prerouting
add action=mark-routing chain=prerouting connection-mark=PPTP_YD_GAMING50 new-routing-mark=\
    PPTP_YD_GAMING50 passthrough=no
add action=mark-connection chain=mark-connections-prerouting comment=\
    "for excluded-addresses bypassing the IPsec IKEV2 OVH20" dst-address-list=excluded-addresses \
    new-connection-mark=avoid-ipsec passthrough=yes
add action=mark-connection chain=mark-connections-prerouting comment=PPTP_YD_GAMING50 connection-mark=\
    no-mark new-connection-mark=PPTP_YD_GAMING50 passthrough=yes src-address=192.168.11.94

So once you add the mangle/output rule above and establish both the PPTP and the IPsec, I'd like to see the output of
/ip firewall connection print detail where dst-address~"ip.of.the.pptp.server"

Then, while pinging 9.9.9.9 from 192.168.11.95, run another command:
/ip firewall connection print detail where src-address~"192.168.11.94" dst-address~"9.9.9.9"

/ip firewall mangle
add action=mark-connection chain=output dst-address-list=excluded-addresses new-connection-mark=avoid-ipsec passthrough=yes

I'm sorry I forgot this chain=output one.
but it's never had a packet even I was visiting sites which are listed in "excluded-addresses" list:

If there is no rule in mangle/output (my way) or in nat/srcnat (your previous way) that would exempt the PPTP transport packets sent by the Mikrotik itself from being src-nated to match the dynamically generated IPsec policy, it means that the PPTP transport packets to the remote PPTP server are sent via the IPsec policy.

Thanks man this one got fixed totally.

Rules in chain output are only used for traffic originating on the Mikrotik itself; when you "visit sites", I assume you visit them from a PC, and traffic from PC to internet takes chains forward and prerouting (other ones as well, but not output).

As you wrote

Thanks man this one got fixed totally.

I supposed that the address of the PPTP server is on the excluded-addresses list. But it either isn't or the mangle/output rule is wrong. Or maybe you actually want the PPTP transport packets to be sent to the server via the IPsec VPN? What's the intention?

Regarding the need to add src-address=192.168.11.94 to the action=mark-routing rule in order to make it work, it smells like a bug to me. What happens if you replace the address to get src-address=128.0.0.0/1 in the rule and try to ping again?

Is it better to send PPTP transport packets via the IPsec VPN (in this way ISP is just see IPsec not the PPTP, right?) or not? in terms of security and performance?

It worked and I can ping but can not open websites or they are very slow.

I started writing an explanation why I suspect it is a bug and how to check that, and during that writing I've realized what is the actual issue. So remove the src-address=128.0.0.0/1 from the action=mark-routing rule and instead place in-interface-list=LAN to it.