anyway you are surely right that having a client which stands in between Orbiter core and the planetary textures would be a very good organization. Actually the point would all be there: put something in the middle between the hard drive files and orbiter to override the terrain definition when (where) needed. I was thinking about creating temporary files that orbiter will then parse and acquire, but I don't know if that is feasible
If you put some area definitions into a text file, you can parse it and use the information at the end of "bool SurfTile::LoadElevationData ()" inside of Surfmgr2.cpp to manipulate the "elev" field in the tile, which is nothing but an 259x259 array of INT16. It is what the renderer will eventually put on screen.
So there you can iterate over all the shape definitions, check if they are relevant for the tile at hand (tile boundaries), then project the shape onto the tile and set the covered pixel to the altitude value you want.
It will not make the collision thing work, but it will demonstrate what the idea could accomplish in terms of developer experience. It will also demonstrate the impact on the frame-rate.