Technically not the game engine's problem if pakset authors do not obsolete their elevated ways to avoid duplicates.
And here we are again, you are completely dismissing the idea that several different graphics for objects with the same or similar values can exist, and not everything needs to be functional. Don't forget other players have different playstyle from yours!
In any case one can select by speed, maintenance then construction cost.
And how do you set it so the ground track that includes a noise protection wall will update to an elevated track with noise protection wall? How could a player exchange an elevated way with one that simply looks different, but has the same speed?
No it does not. The transparency blend fails to factor in colour space correction as far as I can tell. It blends using a non linear colour space in a linear way. Hence approximation, not true.
Approximated transparency is still transparency. Are you saying Simutrans does not support color, because it does not support true color? It might not blend with elaborate logic required in image editing tools, but 'you can see an object and the object behind it both' is good enough, especially for this application.
It is intuitive as one learns very fast that one can drag normal rail over elevated ways and it factors them in. Just currently it does not modify the elevated ways in any way.
You contradict yourself. People can learn many things very fast. For example, a misspelled "length"- parameter in dats can be learned very fast, you only need to know it once and you can 'factor it in'. But if you need to learn it, it's not intuitive - intuitive things are those which work the way you expect them to, based on prior knowledge. Prior knowledge in this case is that you need seperate tools to build ways, elevated ways and bridges. It's intuitive that the same tool at a higher level updates existing ways to that new way. If there was an 'update'-tool which does not build ways, but can update ways to the next higher level, it would be intuitive that such a tool can work for bridges, tunnels and elevated ways as well. If elevated ways were seperated in an elevation and a way, so that you could delete the way without the elevation, or even build an elevation without way, it would again be intuitive to update ways on elevation with the common way tool.
Currently to upgrade a section of track one has to drag normal rail over it to upgrade the normal rails, and then mess around upgrading the elevated rails. With the proposal one could upgrade the line simply by dragging the new desired speed. This saves a lot of user input and speeds up/simplifies the job massively. It should even be extended to bridges, allowing upgrading of bridges without disrupting traffic.
This is effective, yes. It would be nice to have this, without being tacked on as an unintuitive mess players can't figure out on their own.
Currently there are a ton of tests to check for bridges, ways, elevated ways and even tunnels. These could be massively simplified if one treated most way grounds in a similar way. Since all the logic would revolve around the same type, methods could be made to allow distinction when required. Bridges and elevated ways could share a lot of their logic as they are highly similar in some aspects and could be made more similar in others.
Bridges are a mess. Specifically bridge ramps suffer inconsistent logic. This is why elevated ways are not allowed over bridges, even though such cases do exist in real life and elevated ways can free float currently anyway.
So, instead of talking about the 'short-term-solution' of updating elevated ways with ground ways, where we won't agree, let's focus on a long-term-solution that has all the benefits you want with your short-term-solution, without the downsides.
If we had elevation objects without ways on top, we could also have bridge-objects without way on top. Those bridge-objects would be like straight elevation objects, but they are able to float as long as there is a slopewall or an elevation object to both ends. You would not need special ramps for those bridges, since the ramps can be elevated ways. This means they would share a lot of code (especially about what's allowed to be buildt on top) while the way is always the same.