Okay, i've been doing some research and brainstorming and a bit of trial-and-error... and i think i might have an idea, an inkling of how to approach this.
if i set up the system to handle a horizontal and a vertical (since i would not be able to simply pass the movement vector variable into mecanim) i can then tell it to just use that information... and a blending system can determine what's going on. so, there will be a state to trigger the animation to move forward, backward, laterally and diagonally between all four directions. this should cover the animation part of it.
Now comes the fun part which i'm not sure how to do... in theory, if i want to trigger it, i would have to extract the rotational data of the mesh object, compare it or calculate it against the root transform data (i'm not sure how this would work relative to the camera position... but on a static, not-relative-to system, it might help) and if i can somehow detect what direction the mesh is headed relative to it's rotation, then i can then (theoretically, haven't tried this yet, not sure how to set it up) figure out what the horizontal and vertical values would be and then feed those to mecanim. from there, mecanim can fire off the pertinent animations.
thing is, i'm not sure how to really calculate that. I mean, how does one calculate the relative motion of a vector based on it's local rotation?
example: Say the character is moving up... so, vertical with a value of 1. but they are facing to the right of the screen (so, a degree rotation of 90 or so) how would i tell it (without hard-coding in all possible angles which would leave a nightmare of an FSM that'd probably be so clogged it'd bog down the system) to say that it's relative movement is essentially to it's left, therefore triggering the "sidestepping" animation segment in mecanim? is there a way to do something like that?
... if i can nail that, calculating the relative motion values of the vector based off of the local rotation of the mesh object, then the next step would be to confirm whether this would or would not work for a "relative to the camera" movement vector.
here are some numbers that might help further illustrate what i'm going for.
main root movement vector is 1,0 (so, up.)
character mesh is facing 90 degrees clockwise.
so, therefore, the relative movement vector should be 0,-1. (so, it thinks it's sidestepping to the left.
does that help?
here is another mental image that might help illustrate.
Character's root is moving to the right (so, movement vector value of 0,1)
Character's mesh is rotated 45 degrees clockwise from the direction it'd be facing*. (making the actual relative movement vector, according to mecanim, 1,1.)
*so, then it's local angle would be 135 degrees.
better?
... I'm willing to bet that there is an action that does this... or a set of actions... and it's staring me in the face but i just can't figure it out. not knowing what this kind of mathematical process is called is probably also not helping.