I'm going to reply in reverse order to your post today.
re: representation issues
First of all, heightfiels dont need THAT much precision to be quite accurate. 16bit accuracy is all that is needed even at a fairly large height scale to produce terrain without noticable quantization artifacts.
WM internally uses 32bit floats to represent terrain, with the height values fixed between 0 and 1. The primary reason for this is not increased precision but speed; most of the operations we want to perform on a heightfield are continuous in nature, and converting to/from integer is an overhead I wanted to avoid. Anyways, This gives an effective dynamic range of the size of the FP mantissa, which is 23 bits for a float.
To give a more concrete example: with a height scale of 1200m, the smallest vertical increment you can record in WM would correspond to 0.15 millimeters(!). 23bit accuracy is more than enough for damn near anything you or I is going to model. :)
re: modelling issues
I understand exactly what you mean here.. it's really a problem with any digital landscape. What gives a sense of scale? Not the terrain itself -- we're usually using fractals to generate the land, and fractals are self-similar -- that's their whole propery that makes them useful! So the land will by and large look the same no matter what scale we're thinking of the terrain at.
So the answer is, a real concrete scale doesn't really set in until you've brought the terrain into a rendering program, added an atmosphere, maybe some trees, people, etc, whatever it may be that gives the sense of scale.
How to deal with this while modelling? I dunno, maybe some people have some good ideas. v1.0's Explorer mode I've found helps alot with this, if you compose your world right -- but even then its still a problem conceptually. This is one of the reasons the height slider was moved to the leftbar in v1.0, so that you could play with the vertical scale more effortlessly.
I bring you a question (maybe more of a subject for discussion, if you will) about modelling. It's related to managing height when modelling a terrain. I find this topic similar to photography, as there is a certain "dynamic range" the analogic film or (digital sensor) is capable of capturing from the broader range of possible light intensities. So if something is darker than it can be sensed, or brighter, it will get cropped out.
Modelling a terrain is a bit similar, with the exception that we have the hability to shrink or expand the height in order to fit it inside the desired "dynamic range", but then we loose resolution.
So when modelling, how should we look at things? If I am modelling a beach, should I concentrate on seeing the the tiny dunes in te sand? WM alows us to bother with that later, as we can use the Clamp device to scale the beach down to size.. But still, if I am watching a render of a "final" result, I should be aware that certain heights should not be seen as the talles peaks arround. For instance: near the coast, it is very likely that mountains are only 600m heigh, and only deep into the continent they get higher, reaching 4000m maybe.. However, If I look at the surroundings, they are probably only 600m heigher (ok maybe a bit more). What I mean is that localy, the appearance feels the same, but globaly there is a difference. My question is about how should we conceptually deal with this, when modelling? How should we think?
I know we can make some sort of a blurry mask, that will automatically define a maximum height for mountains, but my problem has more to do with interpreting correctly a rendered image and determine whether the height is "adequate".
In my modelling, I tend to forget about the height value and then simply correct things in the end using a height scale that renders it better. This has the drawback that I mentioned above. I think I just discipline myselft to make things right when the time is right.. I just need to know when that is :)
If in the end I come up with a terrain that has a beach, with tiny dunes, then some plains, and hills and mountains with high peaks, I will most likely have lost resolution for the dunes.. Is the only solution to this (using heightmaps) to use higher bit-count: 32bits, 64bits and so forth?
Regarding terrain representations, this topic can also be found in some types of files. For instance DEMs are heightmaps that specify a reach between two height bounds. The files says that the lowest point in that heightmap is 1000m and the highest is 3000m, for instance.. This specifies the "dynamic range" of the data, and distributes the full resolution to that section only. This may cause problems if two tiles of terrains are put aside of each other, as they could have different height resolutions. but that is a different matter, that can be solved with some nice sewing.