Well you could bring it up to Epic but they already know 
Predetermined paths do not work for the same reason state machines won’t work in that root motion already provides the necessary data and the road to success is to ignore all things that needs to be done as to using in-place animation. I was able to get root motion to work by tossing out the state machine and instead used a simple logic tree and multiplexed the keyboard input.
Why RM does not work with state machines is because the state machine requires that the current state has to exit when the state changes “but” also has to wait X amount of time until there is enough frames left in the animation to blend on the exit into the next state with in the sequences of events.It works using in-place because the speed and direction of the movement component is a constant no matter what happens in the state machine as the animation is reactive. Since movement is contained as part of the data set forcing it to wait more or less tells the forward movement to continue so you would get a strange result.
Using a tree the RM animation blend enters from the beginning and uses a weight value and not a wait state so no need for exit arguments. Binding to a path will not work as well as once again speed, location, and rotation is contained with in the animation so for it to work you would need a gimble that generates the data for the RM to follow. Long way to say that since RM is data drive it needs some type of input to work and not bound or dependent on a movement element like a movement component or path.
The thing is all of the parts are there it’s just once again the lack of documentation as to implementation that is lacking
What would be of great help is a RM version of the Shooter example