For player entities Operator: Entity Motion will almost always return (0, -0.something, 0), because the motionX/Y/Z fields used in the operator don't take into account player input (yay Minecraft). This is the case both in singleplayer and in mutliplayer.

Simple testcase, use this spell while moving around and observe the debug output always printing Vector[0, -1, 0] (unless jumping / falling / being pushed by water / other non-input based stuff):
{spellName:"Entity Motion Test",uuidMost:-7026662135838978948L,validSpell:1b,spellList:[0:{spellPosX:3,spellData:{spellKey:"selectorCaster",params:{}},spellPosY:3},1:{spellPosX:3,spellData:{spellKey:"operatorEntityMotion",params:{psi.spellparam.target:1}},spellPosY:4},2:{spellPosX:3,spellData:{spellKey:"operatorVectorNormalize",params:{psi.spellparam.target:1}},spellPosY:5},3:{spellPosX:3,spellData:{spellKey:"trickDebug",params:{psi.spellparam.number:0,psi.spellparam.target:1}},spellPosY:6}],uuidLeast:-6192799415032249109L}

Oh yes, I forgot how retarded player motion is. I actually have no clue how I'm going to fix this O_o

Maybe compare current position to position previous tick?

And then you throw an ender pearl and your motion vector goes haywire? Too many edge cases.

Might be forgetting som other case, but at least for teleportation with for example ender pearls, both position and prevtickposition is set to the same value, so at least in that case the motionvector won't go crazy.

Sorry if there are some spelling mistakes, written from mobile.

Can't think of another way, either. Also, if (magnitude(delta)>epsilon) setMotionToZero() might be good enough to work around edge cases.