KUJU made a strange decision to NOT use the path altitude parameter in the Tsection file but instead to hardcode an offset of 0.325m in the program code to offset the track path from the origin point of the shape. My guess is this decision was made at the last minute when somebody noticed trains were not up on the rails in the last-minute-produced routes that were included in the original cd... essentially a fix could be made more quickly by changing the code than finding and editing the relevant zero in the tsection file.
That clumsy decison then controlled the Tsection specification of all new tracks. Because roads were always flat shapes it was not an issue for roads.
But this is what things look like when you pair road and rail at the same position and Qdirection():

Number of downloads: 5
As things stand with TSRE it appears if you use the offset parameter in the Tsection file a sequence of such shapes will not be snapped together as you would expect but instead placed at the offset point creating a stair step result.
There are two possible solutions: Edit the altitude of the track shape and reduce it by 0.325m... OR fix TSRE so we can specify road shapes (at a minimum) so their surface is 0.325m high but their origin point is at zero -- IOW the dimensions of track shapes.
WRT track with a non zero altitude... there are some defined in the tsection and I have to wonder if they really work. At any rate, the problem is if the 0.325 hardcoded offset is removed from OR all the trains would run 0.325m lower. The only solution to that is a massive edit to the tsection file to replace that zero altitude value with 0.325. It is a do-able task but certainly be a non-trivial effort and the revised tsection will would have to be delivered at the same time as the revised OR code. Because road surfaces have always been at the origin point this particular problem would not apply to them.