ALH

Really? Then please explain why these two produce different results:

/execute rotated as @p at @e[name=WandRay] run teleport @e[name=WandRay] ^ ^ ^ facing ^ ^ ^1 < no rotation happens

/execute rotated as @p at @e[name=WandRay] run teleport @e[name=WandRay] ^ ^ ^0.01 facing ^ ^ ^1 < rotation happens

The only difference between those two lines is the Z coordinate of the teleport command. Now either both of these should fail in teh same way with respect to rotation or neither of them should. The fact they both produce different results shows there is a bug in how that is being handled. Maybe it's in teleport like I suspect, maybe it's in execute and neither of these should produce any rotation.

Thinking on your description of the override behavior, neither should produce rotation.

I believe I have found why this is failing. The teleport command is ignoring 'facing' arguments if there is no change in position. 

/execute rotated as Default_Ex at @e[name=WandRay] run teleport @e[name=WandRay] ^ ^ ^ facing ^ ^ ^-1

Doesn't do anything when it should rotate the entity "WandRay" in the same direction as the player "Default_Ex" (@p gives the same result).

/execute rotated as Default_Ex at @e[name=WandRay] run teleport @e[name=WandRay] ^ ^ ^0.01 facing ^ ^ ^-1

This however works but will require another teleport afterward to undo the change in position

Addendum:

I noticed with arrows and tridents that it actually does try to rotate the entity but it just twitches slightly instead of performing the rotation.

This bug has been incredibly aggravating. I'm running a completely fresh install of Windows due to a mess VS2017 caused. Only things installed are drivers, Notepad++, VS2008, Firefox, Java and Minecraft. Haven't even done any of my usual configuration and tweaking of Windows like I normally do after a fresh install so it's a bog standard Windows 7 Professional install updated without any of the optional hot fixes.

Haven't noticed anything too odd in the logs other than it reporting Java 1.8.0_25 installed, stating it's outdated and that I should install Java 1.8.0_25 before running. I have noticed that when I start the launcher there are 2 or 3 processes called "MinecraftLauncher" running but I wrote that off as not grouping up processes under the same parent process like that horrendous mess called Chrome. While bad practice (as I've been taught) it wont exactly break anything so it's more a style choice.

The thing about when that launcher crashes is that it seems to randomly take out Minecraft with it. Sometimes it crashes out and Minecraft launches just fine. Others it crashes and causes Minecraft to go unresponsive either during loading or world loading. Now I found you can avoid the world loading crash simply by force killing the launcher process before loading a world.

One thought I have is to add a security policy for Minecraft's specific copy of Java, one to escalate it out of UAC. This is a fix that I know works for some software but considering it disables safeguard that protect your computer not just from malicious attacks but also programmer accidents. I am weary of doing that for software I didn't compile on this machine personally since anywhere in transit that executable could have been tampered with.

I know that's one thing that could potentially cause this with Windows Vista on up. If the application doesn't declare what permissions it needs, Windows may not grant them. Ran into that myself with .NET software I wrote and I know there are similar mechanisms (if not the same mechanism) in place for all software.