This is a somewhat complex subject. On the one hand, the needs of Experimental and Standard are different in some respects (I am embarking upon this project because separating the bridges and tunnels from the underlying ways is important for the new feature currently in progress of having ways wear out and need to be replaced). On the other hand, there is much benefit for the separation for Standard, too, and it has been discussed for a time. If I were successfully able to implement this in Experimental, much of the code would be able relatively easily to be able to be backported to Standard. That would have the particular advantage that it would not be necessary to have different pakset graphics between Experimental and Standard.
The unhelpful bridge/elevated way dichotomy makes things more difficult. It would be useful to overcome it somehow (my initial idea was to use the upgrade group/way only cost system that I had initially planned for bridges and tunnels before discovering that separating them from their underlying way was not only more satisfactory but also actually easier). However, if there is a sensible way of doing this by combining bridges/elevated ways into a single, better, type of bridge, then that would be even better. However, I should probably have difficulty undertaking a task of quite this scale alone, as this would require changes much more fundamental than those that I have so far made (I have only been able to go as far as I have because the underlying separation of bridges and ways was already present in the code, but not fully used).
In the circumstances, may I request some collaboration on this part of the task? Whether it is done by first backporting that work that I have done into Standard and then working on that before I extract the relevant parts of the code to Experimental again, or whether all the work is done first in Experimental and then the relevant parts extracted to Standard is a matter for discussion, but, much as I see the benefit in what Kieron suggests, I can only imagine that I should struggle to implement this fundamental a change to parts of the code of which I have a limited understanding alone.
Edit: Also, I am having some difficulty finding any way of allowing a way of one type over a bridge to be replaced with a way of another type, as the way building tool will refuse to find a route over tiles with another way on them, and I cannot find the specific piece of code that tells so to refuse.
Edit 2: Given that it seems unlikely that it will be possible to merge bridges and elevated ways soon, I have implemented the (rather simple) upgrade group and way only cost system, which is useful for elevated ways, but conceivably might have other uses. The system is very straightforward: for any given way, there is an "upgrade group" and a "way only cost". If these are not defined in the .dat file, they are assumed to be zero and the same as the normal cost respectively. Whenever a player upgrades a way with another way, if the upgrade group of both ways is the same, the way only cost is charged instead of the normal cost. This allows elevated ways to be upgraded with other elevated ways that differ only by the surface rather than the structure.
Edit 3: I have now finished at least an initial implementation of this, which is on the way-improvements branch of my Github repository. I have not been able to merge elevated ways and bridges, but have at least introduced the group upgrade cost system described above. The separation of ways and bridges seems to work quite well, although tram tracks over old style bridges are not properly shown, and some canal bridges have artefacts on the towpath that I do not fully understand given that the underlying way is set not to be drawn when the bridge does not have has_own_way=0 in the .dat file. I have not done anything with tunnel portals: one simple option might be just to depict the entry way in shadow, although I do not know whether that works with the shading directions.
I have begun to convert the Pak128.Britain bridges to the new system, focussing first on the brick arch viaduct bridges, and have been able to rationalise considerably so far, removing the need for separate graphics for road and rail bridge for the snow type, and having only one bridge each for road and rail for the non snow type. The narrow gauge implementation of the bridge unfortunately has a transparent gulley along one side where the track is too narrow to cover the expanse of the bridge: it will probably be necessary to have a separate narrow gauge version of the bridge. I have yet to attempt the more complex bridges, so may yet happen upon unforeseen pitfalls, but can always fall back to the old system of letting the bridge provide the way graphic (as will be necessary for the wooden trestle road bridge with its wooden surface).
It is quite a happy thing for the same bridge built in different eras automatically to have different road/track on it, and this really does seem to enhance the game, especially as it will now be so much easier to balance bridges and tunnels.