I’m using the same configuration, same “car” Profile, same CarFlagEncoder.
I tried different configurations but I don’t understand what’s is going on here.
It looks like the route was simply calculated for different start/target points. Map matching uses a different algorithm to determine the snapped points. /route simply takes the closest one, but map-matching considers a set of nearby points. Map-matching then finds the minimum cost path considering all these snapped points. In your example this results in the route seen in your second screenshot: Starting in Rue de Villandry and going to Les Feux results in the overall least costly route, so these snapped points are preferred over those on the two bigger roads.
To use map-matching to support your use case of u-turn prevention at via nodes (Buses: avoid u-turns) it would probably be helpful if we could specify the search radius for the different points. For example here you want a small search radius to make sure the start/end coordinates do not snap onto the smaller roads, while at the bus-stop in your previous example you want a bigger radius to make sure the main road is considered as well. Or maybe it would be sufficient to keep the start/endpoints fixed (use only the closest snapped point for these coordinates). I am not sure if this is possible with map-matching yet, but you should check the usage of the findNClosest method.