Detecting Players not moving

This is functioning as intended. When accessing pre-existing list data (denoted by square brackets), each record you define is scanned throughout the entire list on the target. Your first 0.0 is checked in all slots on the player's "Motion" tag, so if their X, Y, or Z motion is 0, it will be found. The second and third records you've defined in /testfor do the exact same thing, meaning they're redundant. It's essentially the same as doing:

/testfor @a {Motion:[0.0]}

This is how we can perform lenient NBT checking; otherwise we wouldn't be able to detect anything accurately in any list tag (such as Inventory, Lore, ActiveEffects, and all other list tags).

For players, you can use the movement statistics while constantly subtracting them when higher than 1; if they are all 0, the player is not moving: stat.boatOneCm, stat.climbOneCm, stat.crouchOneCm, stat.diveOneCm, stat.fallOneCm, stat.flyOneCm, stat.horseOneCm, stat.minecartOneCm, stat.pigOneCm, stat.sprintOneCm, stat.swimOneCm, and stat.walkOneCm

Duplicates MC-73887

I felt embarrassed....

btw, I still don't get the answer,
I tried with Motion:[0.0,0.0,0.0] and Motion:[0.0]
But it's still on when I sprint,walk or sneak, it didn't even off when I fly.
Again, The command only failed when I jump while sprinting.

I just can't get it.... When will the player's Motion becomes non-zero?

"Motion:[0.0,0.0,0.0]" is exactly the same as "Motion:[0.0]" when detecting pre-existing data.

If the player is moving in the X direction, their Z and Y will be 0. Your command finds that 0 as a match because a check within list data is a scan throughout all values on the target, not in the order you specify them in. If the player is moving in the Z direction, their X and Y are 0. If they are only moving in Y, their X and Z are 0. If they are moving in all directions X, Y, and Z (moving diagonally across X and Z as well as up/down such as from jumping), then they have nothing that is 0 so the command fails.

So how to detect all zero?

Please accept impossibilities (is that even a word?) as you should.

If more than 3 ppl here said it's impossible, I'll give up.

@Joshua:

For players, you can use the movement statistics while constantly subtracting them when higher than 1; if they are all 0, the player is not moving: stat.boatOneCm, stat.climbOneCm, stat.crouchOneCm, stat.diveOneCm, stat.fallOneCm, stat.flyOneCm, stat.horseOneCm, stat.minecartOneCm, stat.pigOneCm, stat.sprintOneCm, stat.swimOneCm, and stat.walkOneCm

In terms of direct NBT data, it is simply impossible, which you've observed on your own (leading to this report).

it seems to be complicated to testfor complete standing...
Ok, it seems this evidence is enough for me to gve up.
Anyway, thanks again.

So the best way I've found to make a motion comparison is to make 3 dummy scoreboards (one for each axis) and have any entity you are comparing store each axis's movement separately in those scoreboards. Then, make the comparison BASED on the scoreboards, rather than raw NBT data. This is accomplished through "/execute as [Target Selector like @e] store result score @s [Scoreboard Name for one of the axis's] run data get entity @s Motion[(0,1, or 2 based on which axis (x, y, or z) you want for this command, make sure the scoreboard name matches)] 100" running in 3 repeating command blocks set to always active, with each command block set to different scoreboards and the different axis's. This way, whenever you want to know if an entity is not moving, it will have an X value of 0, a Y value between -8..0 (due to Minecraft applying downward motion constantly when an entity is on the ground), and a Z value of 0. Of course, you can now target select for this condition and it will only be true when that entity is not moving. If you want more precision you can increase the scale factor at the end of the data get command (I use 100 because it is enough for my purposes), the only difference is that the entity's Y motion will increase by a power of 10, and that allows for less rounding (at a scale of 100 it is -8..0, but at a scale of 1000 it would be technically -79..0 due to the previous number being rounded. The real force downward is -0.0784000015258789, so just round this to your scale). Hopefully, this will help someone else!