Sethren, what’s unique about Dmytry’s erosion is that he’s able to do it procedurally at all. That it has theoretically “infinite” detail, just like normal procedurals. It’s not really the specific look or result of his erosion that is special - it’s not like he’s simulating some new type of erosion. It’s just special because he can apply it procedurally.
Erosion is usually an iterative process performed on a per-heightpixel basis and thus is inherently a finite resolution process. The simple way to get “infinite detail” erosion would be to sample a procedural terrain 1 height element per screen pixel (or more, ideally, for AA) and do erosion on that, though it would require some very complex manipulations for even that to work, and even if it did it would be very slow because each frame would require a recompute of the erosion for the entire visible terrain. What Dmytry has done is figured out some way to actually apply an erosive-type filter to a terrain and keep it procedural - or at least that’s what he claims and what the results he shows indicate. Read up on traditional erosion models and then on what Dmytry is doing (he’s written about it some before), you’ll see the difference.
Monks, I’m fairly certain I do have that pdf somewhere but I’ve been through 2 computers since. 
I’ll be able to dig it up at some point, but not immediately. Feel free to keep bugging me about it.
As far as doing ice/glacial erosion, basically you need to do the following:
1: Determine what effects ice actually has on a terrain and how it moves over and/or accumulates on the terrain. This sets the tone for everything to follow.
2: Determine what factors are involved in those effects. What is the effect of ice on different terrains, rock, soil types? How does slope affect it? etc.
3: Presuming (hopefully) 1 or at most a few major definable effects and a few “factors”, you create 1 or more mathematical models that simulate those effects using simple per-pixel heightfield modification functions - add, subract, multiply, or more complex, but still operating directly on the heightfield based on some fairly simple rules. This is essentially how most erosion models work. You start with “rain” which defines a property of a certain amount of sediment carry, etc. which expressed mathematically is just a certain chance of picking up x amount of material and then y chance of depositing x amount of material at each point of traversal, at which point that “drop” stops. That’s a very gross simplification and Stephen may take issue with it. But the point is that it really just comes down to simple operations on the heightfield based on a mathematical interpretation of what water does in the real world.
4: You create a device based on these simple mathematicla models of the effects of ice and the factors involved in its effects. Examples of this in the current device are the “rock hardness” values - take the real-world idea of rock hardness, which probably takes into account slope variations, etc. and then translate that into a mathematical effect on the system. In a glacier/ice model slope would probably figure heavily into it. You might have a “slope sensitivity” or “effect of slope/gravity” control. Figuring out what other controls you’d have and how they would translate to mathematics is the trick.
5: Once you have all this it should be a fairly simple process to create an input that determines where ice initially starts. An “ice mask” which would be defined just like any other mask in WM right now. No need to really have some new device type or anything, the “ice” would be unique to the “ice erosion” device though. So you couldn’t model ice globally throughout the device chain, just in the one device. But it would have output for “final ice deposition” or whatever too, so you could then take that in to your 3D app and texture it properly, etc.
Now this is more complex because ideally you want to define a difference between ice and soil, where ice will also have volume. SO it’s separate volume. Whereas a regular erosion model just moves the same “stuff” around - it’s all soil. So depositing a chunk of soil here just makes things higher, the model doesn’t keep track of what new soil is there, except to record how much soil was put there with the masks. But resulting heightfield incorporates that deposited material.
I suppose it might be possible to output the ice normally as part of the heightfield, but then to optionally just take the ice mask output and subtract that from the terrain, resulting in the soil height itself. Then you use the ice mask output as your “ice volume”, maybe a separate heightfield in 3D apps that allow that.
I dunno I’m just blabbering here really, but this is the immediate, practical way I see of doing it, that fits within the current WM paradigm. Actually having some different data type for ice, if that’s what you were suggesting, seems more out of left field.
Sethren, TG2 probably won’t meet your needs for specific large-scale terrain creation. It will certainly have a heightfield editor in it and good procedurals, but unless you feel Vue and/or Mojo currently offer you what you need (as both have the separate elements that TG2 will better combine - heightfields and procedurals), then you probably won’t be that much better served by TG2. WM will still be a better terrain modeler in general I think, for heightfields at least, especially with Pro.
We’re talking about rivers at the moment. Imo, rivers are THE most important consideration for this scale of work because at this scale you get to see the whole of the hydrology cycle, not simply a part of it. Mountains to sea to mountains.
)