Mostly the scenery developer rise the line meshes (ca. 10cm).
Mostly they do not (because these lines are real geometry and wold be an obstacle for taxiing) - it would appear that rarely some lines are raised in the mesh (never seen one myself) from the reports - if that is, it is by accident and not by design.
But if you switch to a external view and look extremly flat over the ground, you notice that the lines are above the ground.
Let's try this again:
What you see on the screen is what the shader code renders, not what the underlyinh geometry is. That's different, because a vertex shader can displace things on the screen, a geometry shader can create new mesh parts, but the collision detection operates on the un-displaced original mesh. The taxiline flickering is addressed by such a fix - the line is displaced on the screen, but the geometry is still flat for collision detection.
In fact, the line is displaced based on your distance to it, so from the near-zone, it isn't much displaced at all, only when you're 100 meters away and the z-accuracy drops, it is moved more and more towards you.
That's the second advantage of a renderer-based fix over hard-coding this in the scenery mesh - you can dynamically react to the situation,
All textures (mostly alpha) that are used to paint on pavement (lines, numbers, signs, etc...) should have a priority higher than 0.
Why don't you look into how FG creates and textures a runway first and then explain us how it's done and what should be done?
The scenery developer dont need to rise the meshes of paintings.
And in fact they do not (I wonder if you realize at all that these lines are created automatically by TerraGear from airport description data).
So, if 2 or more textures have the same value in the z-buffer, the textures will be rendered in ascending order of the priority.
1) Textures have no value in the z-buffer, fragments have
2) Multiple textures are drawn on fragments as the fragment shader code says, not based on mysterious priorities