Thanks for keeping us updated, sounds like a very interesting journey :). I am happy to hear that the process so far worked well.
Maybe the easiest way would be to create a new PR, simply adding the file and allow edits from maintainers. Once the other EP PR is merged, either I or maybe you (if you have the time and feel like it :)) could finish up the PR. It should be straight forwards if you did not change a lot of code from the SRTM provider.
During manual testing and debugging I noticed that the rout calculation will often fail when one of the via points is a considerable distance from any road or track. Moving it closer will make the route calculation work again. This never happened in the old GH.
Is there a maxmimum capture distance for the via points?
Is it possible to adjust that?
How large is āconsiderable distanceā? Is it really meaningful to return a route in those examples?
You can tune this via the location index settings preciseIndexResolution and maxRegionSearch, where you could easily increase maxRegionSearch but adjusting preciseIndexResolution is more delicate and should be avoided (impacts location index query performance vs. location index size)
The use case is meaningful. In my route editor, you add a new via point between two existing points by clicking on the line and subdividing it. This new point may be a long distance from any route. You have to move it there then. But now you have to click away the error messages for failed routing that keep popping up.
It seems that the problem is not so straightforward. In the debugger I found that the lookup of the all 3 points is successful. The queryDistance of the point in question is 292. Snapped points have been calculated for all 3 points.
I found the problem. It is the hint pass_through. When I disable the hint, I get a routing result.
Example 1: routing fails
Example 2: routing works
Experimenting brought the following results:
When pass_through is activated and the snapped point is the end point of a dead end way, GH fails the routing.
When pass_through is de-activated the same point works.
When the snapped point is on the dead end way, but not the end point, the routing works, too.
I think this is a bug. GH should accept an unavoidable U-turn at the end point as well as in the middle of a way.
The new version is now live on my server wanderreitkarte.de. I have disabled pass_through to avoid the routing failures discussed above.
I must say that I am impressed with the speed of GH. Routes with 200-300 points are usually calculated in less than 10ms - and that is using only flexible mode with dynamic weight calculation. Iād really like to congratulate the GH team to that performance achievement! 
Thanks for the kind words and please create an issue with a link to your nice findings!
I wanted to share the response time statistics of my server. Impressive. You can probably guess when GH 0.9 went life. 
There are still single peaks where it takes almost 2 seconds to respond. I assume these are requests where there is no connection between two via points. I have set routing.max_visited_nodes = 500000 in order to decrease the answering time for hopless requests. Is this a reasonable value considering that I do not allow more than 100km between via points? Is it the right value at all?
Cool, this looks really good 
Are you using landmarks or completely without any speedup?
You have to experiment and compare inner vs. outer city how long routes can be with that value.
That is with multiple dynamic parameters for the routing and no speedup features.
If you have parameters that do only increase certain edge weights (e.g. traffic jam or block roads) you can still use landmark preparations and depending on the detour the performance is still very good.
The parameters can both increase and decrease the edge weights.
And i am very happy with the speed anyway. 
If that is the case one can usually start with the lowest and use this for landmark-preparation and then apply higher weights while routing. But if you are already happy with the speed ā¦
Well, I think it would be mathematically possible to transform my calculated weight factor into a minimal weight based additive system. But in its current form the rather complex weighting rules are human comprehensible and I prefer to keep it that way.