Player Motion data no longer updates while riding another entity

Can confirm

Also can confirm:

while of course we'd appreciate a fix to this bug, a better resolution would be a proper way to receive player input values & events, and if that means waiting another snapshot cycle or 2 the commands community would rather have a more polished/intentional method, as NBT access is bad.

It's probably good to clarify that the effect that disappeared in 24w33a was invisible without looking at NBT. It didn't move the camera and it didn't influence the mount entity unless it was a horse or something. The only effect that I know of was the effect on the player's Motion NBT.

Though, there is probably a side effect where projectiles shot by the player would have their motion shifted according to the player's WASD inputs, but I never verified that that was happening in the first place. And I'm not sure that it matters, because I don't believe anybody was relying on that functionality anyway. At least, I've never heard of anyone depending on or using it. And in case it's not clear what effect I'm referring to, I'm guessing that before 24w33a, if you were to /ride an armor stand and shoot 10 arrows, all at the exact same angle, and then shoot 10 more arrows while holding W (forward), the latter group of arrows would shoot slightly further than the first group, on average. If you held S and shot 10 arrows, that group would get the least distance. Like I said, I don't know if Minecraft was doing that prior to 24w33a, but I bet it was, and as far as the mapmaking community goes, I bet that it doesn't matter if that behavior is lost.

EDIT: More importantly, in case a full on "input detection system" isn't on the table for this update and this behavior must be manually re-added, I'd like to suggest a small design change. It might be better for the player's motion data to change depending solely on the WASD inputs, not both the WASD inputs and the player's rotation. When the motion data changes depending on both, we have to do our own logic to undo the influence that the player's rotation has. Instead of complicated (and slow) logic where we have to find the angle of the motion vector in degrees, then compare it to the player's rotation data, it'd be very nice if we could just say "if the player is holding W, their X velocity is 1.0d. If they're holding A, their Z velocity is 1.0d. If they're holding W and A, their motion vector is [0.707d,0d,0.707d]," regardless of what angle the player is rotated.

This would be great because, in the past, the motion vector didn't update immediately when rotating the camera, so if you held W and turned your camera, the datapack would often detect some other inputs instead. Choosing to not depend on the angle that the player is facing would solve this delay problem immediately, while also making WASD detection simpler in general. Now, there are some people doing logic as simple as "add the player's motion vector to their mount," which is useful because, if you want to create some kind of custom mount, then using that logic will let the rider influence their mount in the most simple way possible: "Hold forward to move forward." So making this change that I'm asking for would make that more difficult. However, as someone who actively uses both uses cases, I'd prefer to have the motion vector never change based on the player's rotation because it would fix the delay when turning the camera, and if you wanted to reimplement that "hold forward to move forward" behavior, you would just need to do a little math to rotate the player's Motion data based on the player's Rotation data. So either way, one use case will need to do extra math, but one use case is more popular, so it makes sense for it to be the one that gets simplified. Especially when fixing that one removes a delay that otherwise could not be removed.

Seems not fixed in 24w36a, can someone confirm please ?

They added a predicate to detect inputs instead

Thank for the clarification.