/tp @s ~ ~ ~ acts like an absolute teleport, killing all momentum

Code analysis (very rough since there are no mappings):

In 1.12.2, the game checked which arguments were relative, and marked those as relative when it created a Player Position and Look packet (it created a Set which it passed to one overload of NetHandlerPlayServer.setPlayerLocation).

In 17w46a, Brigadier is used, which means the command no longer manually parses whether it's relative. setPlayerLocation is then used without a Set, so all values are absolute.

I agree that this seems like a bug, or a partial regression of MC-4686. (Have not confirmed this in-game yet, though)

I can confirm that this bug affects the new ^ notation as well, making it much harder to use with players. Since the rubberbanding affects player rotation, this causes players to be unable to change where they are being teleported if a local teleport is run on a clock. This doesn't seem like the intended behavior that ^ was stated to have.

Also, even though these teleports (including in the release version with the right options) stop all motion, it unintuitively doesn't reset fall distance, so fall damage build-up is another potential problem here.

Hopefully something like a "keep momentum" argument gets added to the end of the command in addition to fixing the jitter, I think that way the merging of tp and teleport will be truly complete while fully retaining the functionality of both (and ideally fixes fall damage buildup if keep momentum is false). Would be nice if "keep momentum" also optionally shifted the horizontal momentum around to match a new rotation, if changing that (as well as preventing the player's hand model from suddenly spinning around to match the new direction (regardless of teleport type), which itself is partially bugged depending on how much 360° rotation you've built up in one direction (see MC-121855 for rotation info)). Something like /tp @p ~ ~ ~ ~ ~ true/match/value where "true" is for the normal momentum-keeping property we're used to; "match" to cause it to match the horizontal rotation that you might set (e.g. walking forward, teleported 90° left or right, momentum will seamlessly match new orientation); and "value" to instead shift any horizontal momentum in a direction using 0-360° (with optional tilde notation... which I guess would remove the need for "match" since ~ by itself would function the same way I think).

Sorry... Looking over it as I proofread, I suppose most of this comment probably doesn't belong in a bug report tracker, but I really had to get all this off my chest right now before I decided "Ehh, maybe I'll write this some other time" (which consequentially would likely be a chain reaction of many more "maybe later"s).

There is still a partial issue with vertical momentum of an entity being cut off while using the teleport command in a repeating command block. Refer to the comment I added to MC-121598 for more details. I tested the repeating teleport command on myself and I fell right to the ground, but when I summoned a zombie it would remain in the air as if it had NoGravity set to 1 until the teleport command stopped executing. The zombie is still able to move freely on the x and z axes when the teleport command is active, but it is unable to fall. Using this command in a superflat world covered in bedrock:

/execute as @e[type=zombie,limit=1,sort=nearest] at @s if block ~ ~-3 ~ bedrock run tp @s ~ ~ ~

and summoning a zombie up several blocks to give it some momentum, instantly upon falling to a height of 3 blocks off the ground the zombie will just float there and spin around, with all vertical momentum lost. Adjusting the command to detect bedrock at the location of the zombie (yes, at its location) will allow it to move freely. Making it detect bedrock 1 block below the zombie will cause the glitch in the screenshot I added. The zombie will float 1 block above the ground but can still move around freely, such as chasing a villager.

That may be a separate issue. Please create a new ticket.