Probably a lot of intervening answers, since this is so long, sorry :-)

Quote -

Pretending for a moment that I know nothing, I'm curious about WM in the general non-hobbyist CG world, versus what we will have.

Please correct me if I've misunderstood some points.

1. Daz trademarked the name "Triax" (TM) in conjunction with DS4. It refers to having 3 independent rotational weights for each joint, one per axis. This implies that the larger CG world has always used only one weight per joint. Is that the case?

This is likely the case, but the reason for that might not be that obvious; The larger CG-world normally does not use Euler angles for posing, but rather quaternions or axis-angle representations. With these you normally cannot easily map your weights to static fixed axes. So the idea of using only a single weight suggests itself.

Quote -
Is using a separate vertex weight per joint*axis a new idea? If the rest of CG apps in the world use only one weight per joint, then doesn't this ensure that the Genesis figure is not compatibly rigged for apps like Maya, etc.? If it isn't a new idea, then what's the point of crowing about playing me too - like me giving a proprietary name to "glass of water".

In other systems, like Maya or blender (i do not know the others), you can usually define multiple weightmaps for each joint if you wish to and bind them to practically any parameter. So you could make a weight map for each joint axis, but why should one do so (unless you want to use euler angles, of course)? The three different weight maps would probably be the most straight-forward way to convert an euler-angle-axis-mapped skin for use in e.g. blender, but usually people do not want to have euler angles in the first place.

Quote -

2. Is "Triax" (TM) actually useful? Does it make a meaningful improvement over "Monax" (TM I made that up). And if it doesn't really make a difference, is it worth tripling the memory requirements to hold all that vertex weight data in memory? How often do you really want the weight of each axis to be different? If it's rare, I would think that it would be better to use Poser's strategy of multiple influencers per joint. This way, you start with a single weight map, and for the few joints where you need unique values for a second or third axis, you would then stack a single-axis weight.

I guess it could be useful from a technical standpoint, since you just have more parameters you can tweak. I do not see the memory issue, because the guys implementing the skinning algorithm should be smart enough not to store the full set of zero-weights (but here i could be mistaken, of course).

Quote -

3. Genesis seems to be one big mesh - no groups. Does this mean that each weight map (per joint) must include data for every single vertex in the whole figure? Isn't that horribly wasteful? Is it sensible to have influence data for every joint * every axis * every vertex? Let see - approximately 45 joints in a figure, times 3 axes, gives us 135 numbers that must be kept per vertex. Even if all that is kept in single precision floats, not doubles, that's around 38 megabytes of data! I hope to see some amazingly realistic human shapes for that cost.

The usage of groups for skinning (and morphs), at least partly stem from the desire to import wavefront OBJ files into poser/DAZ, i think. And with OBJ you cannot do much beyond creating groups for various sets of vertices (faces actually). Since DAZ can invent some new proprietary file format for their "triax" system, they do not have to bother with this limitation, so i guess the file size does not need necessarily to grow. Makes things more difficult to import in other applications, unfortunately. But comparing the mysterious binary undocumented DS file formats with the relatively easily understandable text-based poser file formats, i would guess, DAZ does not mind anyway.

Quote -

4. SM is notorious for not knowing how to use its own tech to best effect, and therefore creating a community perception that the tech is far less than adequate. As far as I can tell, Miki3 does not demonstrate at all what is possible with the new multi-zone sphere+capsule system introduced in P8+PP2010, the system that Daz has refused to embrace. Instead, they claim that Poser tech is holding them back. Meanwhile, I notice also that last year, Maya (an app that is over $3000) just introduced the same or similar multi-zone capsule shape rigging that Poser did, and they talk about it as a way to seriously avoid having to weight map for realistic joints - that it is a step beyond painted weight mapping. What's the truth here? Any rigging experts care to comment?

I am by no means an expert on the matter of subject, but before i even knew that poser and DS existed, i had a bit of experience of weightpainting in blender and a little maya. And before i actually tried poser i got this book "Secrets of Figure Creation in Poser 5" by B.L.Render (that one gave me the idea to actually try poser). The first thing i thought when learned about the falloff zones, was that these are actually an improvement over the older weight painting system, because the falloff zones essentially specify how your surface should bend when bending a joint, whereas with weightpainting, you specify how each vertex should bend. At first this may sound like the same thing, but with the falloff zones, one could use the same zones for different meshes. E.g. you could completely redesign the topology of a limb and still use the same falloff zones. With weightpainting you practically start over and have to redo the weightmap. So i think that Maya does the right thing by implementing those, since it makes it easier for the figure creators; function-wise it is the same, of course, i would even suspect that internally those applications that offer falloff zones use weightmapping internally by converting falloff zones to weights, when loading a figure (i guess even poser does that), since weightmaps are more natural for a machine to process (falloff zones are more on the human side of thinking).
In summary this so called "triax" system sounds a bit like the worst of two worlds: You have still have to use those nasty euler angles with the costly creation of weight maps. (Maya probably does it the other way around, at least i hope so :-)