I think, the forward backward feature is no longer needed.

You get me wrong, I didn't mean the 'REVERSE_CALC_ROUTE_TOO'. I (want to) said, that if you have only several starting tiles, but only one end tile, you have to do two searches: First A -> B, to find the best tile at B and then B -> A, to find the best tile at A, however, it's possible, that you don't find the best combination of tiles at A and B.

Its main effect were different bridges (since those started on different tiles then) and the first curve. However with the new bridge implementation and with several start tiles there will be only very special cases where it makes a difference.

That isn't true in general. The current implementation isn't perfect: It won't find a road connection A->B, but finds B->A in the appended screenshot.

For the endtile a rectangle heuristics may be best. Only for abs_distance<2*size there will be checks for zielpos.is_contained().

I'm not sure, if this is needed. A heuristic, which is 0 on the rectangle (resulting in an BFS), would be sufficient, imho. And maybe a heuristic, as you suggest, isn't a monotinic heuristic for A*.

Does the ANode-array in route.h takes 19MB (max_route_steps = 1,000,000), or I am failed with simple arithmetic? Then much memory would be needed, if every AI gets its own routefinder. But it's a very elegant idea. Maybe we should think of one array for the player and one for all AIs?