I use both systems interchangibly, Mecanim more for mapping out what animations are needed, handling most imported humanoid animations, and putting in clean blends of the animations our animators bring in. While I typically use Legacy on animations built from scratch directly in unity, or when the animation needs to be tightly coupled with certain components on a gameobject.
My Animator Controller has 6 layers (“Base”| includes Hips down, “UpperBody” |includes torso neck and head, a layer for each arm and a layer for each hand). In the root state on each layer I have a collection of substates named against the item the player would wield (like a Sword) or ability they could do (like climbing ladders) within each substate it can be broken up further but nearly all of them would have a Movement state (a blend tree of root motions) and any action state animations (equip/unequip, enter/exit, pickup/drop, Use, Aim, block, recoil, etc.). movement state will typically be the idle state
I actually use the Third Person Controller Asset from the asset store which doesn’t really link states together with transitions (instead uses crossfades via code). and its made setting up character animations easier. I actually don’t use the “Any State” at all. Only transitions I make are those where a specific animation shouldn’t be interrupted and must follow through to the last animation
I also use Legacy system to great effect as well. and sometimes I don’t use it as an actual Animation system, but as a way to interpolate a significant number of properties on an object with a singe Lerp value, especially for Particle systems (where not all the properties are easily accessible via code). could you imagine setting up dozens of Lerps for properties in the particle system (and only on the properties you could change at runtime)? The Animation Panel and its keyframing trivializes that. And in this sense now I don’t see the time slider as a time value, but as the lerpvalue I would feed into Animation.Evaluate. it actually works pretty well for my procedural fires.
This is my stance on Override controllers. I don’t like them. Don’t get me wrong they work for what they are designed for, but they are far too lacking…
for starters if you have two states using the same clip (but for different circumstances) you have no control of which state get overridden and which won’t, either you have all instances of that clip overridden or you have none. Override Controllers only tracks unique animation clips and fully remaps all instance uses of a specific animation clip to another clip.
the another issue is with blending. a certain transition may have been set up with the perfect amount of blending between two clips. and while the controller is mostly the same, with the two animation clips being different you might want slightly different blend settings. Override controllers have no support for that
And finally the last caveat is with StateMachineBehaviours. now if your SMBs lack SerializedFields (as in theres no fields drawn to its inspector) then theres no real issue. but if you do, then what ever you have in the base controller will have to also work for any overrides, cause it can’t be different in the overrides.
Unless your Controller is simple, I’d say you’re just better off duplicating the Controller as a new asset. It does mean more maintenance, but Override controllers just don’t save enough time on hardcore Controllers to be worth.