Hi Folks, hi swOOOOOp, thanks for checking out the video and for your comments 
Respectfully, I'd like to make a few points:
* This isn't simply a reworking of *inis like those which I've already made available for download. Thing is, it's a reworking of the default morph data, with a lot of new morphs mixed in. As I say in the vid, there are licensing issues (mesh) - as well as development issues which RL would need to consider if this was to become genreally available to the user base. By development issues I mean the implications of a new and more powerful base morph set - particularly issues of conversion and backwards compatibility (which I've already taken into account, but without procedural tools many users may find difficult).
* subtle eye movements - sorry, I meant very subtle - as in, the way both bottom and top eyelids are affected by eyeball motion. This is demonstrated in the video - but you need to look closely. In terms of other motions - there are subtle neck as well as facial movements which are dependent on the capture resolution (and noise/ cleanup required) of the mocap system. Hence better use of the existing morph/bone approach can potentially provide a higher resolution, as well as quicker/ more convenient and cost-effective solution than conventional mocap.
* shoulders - yes, they do need work. Quite simply, the torso to arm front and back (pec/deltoid and trapezius) lower intersections (that's an anatomical way of describing armpits...) remain way too high, resulting in an unnatural base mesh whether static or animated. This is an important (and obvious) fix - the difficulty is in balancing vert positions with bone weights. It's doable (I've been doing it for a while on individual character meshes), and should be incorporated into the default.
* regarding importing other rigs/ using Max (or any other 3Dsoftware to redefine default controllers) - the issue is, this makes for a non-standard avatar. The ideal would be to solve all issues with the default mesh/ rig - so that all users could benefit - as well as reuse all previous models - and use animation data from previous models (only with the advantage of having a more powerful system). I'm saying this is generic stuff - as in, how to upgrade RL's tools and maintain backwards compatibility.
* progressing morphing - swOOOOOp's right: the workaround in the *inis is to use relative values and think in terms of speed ie how fast one morph will apply relative to another. This is encoded progressive morphing, and it's how I'm adjusting the morph blends to get the effects shown. I agree it's tedious work, but the results are rewarding - and tbh I can't imagine RL prodecuralizing this via the UI when there's so much else - and so many easier/ more obvious fixes to do - which will no doubt take preference.
Finally, the biggest frustration for me is not the lack of deep tooling to do this kind of thing (I've spent a lot of my 3d career doing this kind of generic remodelling), it's the fact that I keep coming up against unnecessarily closed areas of software, which limit the potential to improve quality. RL are quite unique in providing such limitations to an 'unlimited' 3D pipeline - but then I think that is because so much of the business focus is on content, rather than improving tooling and base datasets. This isn't a criticism - simply an observation: the fundamental issue for those of us who want iClone to realize the potential that we as users would like see is to get around the fact that it's potential is inherently limited - for business reasons. There's a conflict here: selling and protecting content for a closed source 'captive' game engine means necessarily limiting what users can put in - and take out of it. So when users (like me and many others!) really want to improve things, we find ourselves banging our heads against very carefully designed walls - you see ultimately, RL decide whether a new function will be implemented or not. And after all - even though we buy it - it is their software...!
Mike (3Dtest)