I can't speak for the D3D9 client with any authority, but since the source data (meshes, tile elevation files) are shared between all clients, it stands to reason that they must have compatible scaling strategies.
Currently, there are two separate ways of defining non-spherical celestial object surfaces: either by defining a single mesh for the entire body, or by using the multi-level quad-tree tile strategy described in Doc/PlanetTextures.pdf. The former is mainly used for small bodies which don't need a scalable approach (and which are not landed on, since there is no collision mechanism in place other than a virtual sphere at the mean radius). The latter is used for larger bodies, where rendering the entire surface even when in close proximity would be prohibitively inefficient, and where vessel-surface interaction handling is important.
I am assuming you are referring to the whole-mesh version - is that correct? The data format for the quad-tree approach should be reasonably well described in the documentation, but let me know if anything is unclear.
As regards the whole-mesh approach, you are correct - the vertex coordinates are expected in units of the planet 'Size' parameter (as defined by its config file). This was originally done for internal reasons (to make the transformation matrices used by the renderer compatible with the other planet render mechanisms), but it also has the added benefit of allowing to change (or correct) the planet size by changing just a single config parameter, rather than having to scale the entire mesh. This is how the DX7-based engines (inline and D3D7 client) are handling it. If the D3D9 client is doing something different I am unaware. Maybe to test it you could try the latest Orbiter development build from the github page. This should minimise the risk of using an out-of date D3D9 client.
In general, I would discourage the use of whole-mesh rendering strategies for new projects, for the above mentioned limitations. Using the quad-tree approach is a bit more complex, but is more versatile. In any case, I have no plans of changing the way the whole-mesh rendering works (other than maybe eventually phasing it out).