You will need to use Encryption Domains Per Community, and possibly per-peer. You also need to have specific VPN domains for each gateway's Remote Access community. Like so:
The US gateway RA VPN domain, attached to RA community, needs to include the US site networks and the 10.10.10.0/24 network.
The IN gateway RA VPN domain, attached to RA community, needs to include the IN site networks and the 10.10.10.0/24 network.
The US-to-M site-to-site VPN domain needs to include the US RA-VPN pool and the US site networks.
The IN-to-M site-to-site VPN domain needs to include the IN RA-VPN pool and the IN site networks.
On the Site M router, the crypto ACL/VPN domain attached to the US peer, needs to include the US site and RA-VPN pool.
On the Site M route, the crypto ACL/VPN domain attached to the IN peer, needs to include the IN site and RA-VPN pool.
In the access rules, you need to be sure you have sufficient rules to allow traffic flowing in all directions. If you're not using access roles for your users, then you have extra rules to consider. For the "legacy user access" rules, which are only attached to the RemoteAccess community, your destination column needs to include the Site M network.
For the site-to-site VPN rules, your source column needs to include the IP pools of the two gateways, and the destination column include the Site M network. You also will need a converse rule.
When your client connects a gateway, for Windows run "netstat -r" to make sure the client has the correct routes installed for the 10.10.10.0/24 network. Now try your ping.
FYI: until the connections are working, using tracerotue to troubleshoot a VPN will be ambiguous at best; unreliable at worst. I would never rely on traceroute as a troubleshooting command, unfortunately. Your best troubleshooting is the route table on the client and the logs in SmartConsole or "fw monitor" on the gateway.
This configuration does work; I've done it plenty of times.