As a mapmaker I spend most of my days surrounded by command blocks (not saying all mapmakers do though) that leads to me using a lot of different techniques and commands to make things work. As minecraft is limited we are forced to be creative because of it. That means using whatever minecraft has given us. Because of this I get to see a wide variety of bugs just because I need to utilise minecraft to its most and therefore most areas of minecraft are covered (pvp, movement, entities, commands, chunks, etc).
I've made this due to me discovering a bug which I think is exclusive to 1.9+ (this needs testing). If it is a bug (which I'm pretty sure of) it is a very pesky one.
Steps to reproduce:
First part:
1. Create a "Superflat" -> "Void" world.
2. Type the following command:
/scoreboard players tag @p add Test
3. Type the following command (do so while floating):
/tp @p 1000 10 0
4. Type the following command:
/say @e[tag=Test]
5. Type the following command:
/tp @p 800 10 0
I think subtracting or adding any number above 100 will do it.
6. Type the following command:
/say @e[tag=Test]
Second part
Follow 'First part' proccess till #4.
5. Type the following command however many times you want (at least twice):
/tp @p 1000(+50) 10 0
So add 50 to the absolute value each time.
5. Type the following command after you run the above command (do so every time):
/say @e[tag=Test]
If the bug occurs:
The first part should prove the bug. When you tp to 1000 10 0 (only the x co-ordinate is relevant) you're actually not loaded (according to the game), but it isn't updated yet. However when you drastically (min of 100~ blocks) change the co-ordinates it updates and you'll be out of the spawn chunks (I assume). Now after this no matter what command you type, as long as it contains @e where you can be targeted it won't actually target you. The second part shows that minimal changes (around 50 or so blocks) don't really cause the player to be updated.
For example, the following commands would all work without the bug occuring:
The argument doesn't need to be there.
A) /tp @e[tag=Test] ~ ~10 ~
B) /say @e[tag=Test]
C) /effect @e[tag=Test] speed 1 10
The above commands all fail to target the "unloaded" player after the bug occurs. This isn't limited to only affect @e though. @r which can target entities via 'type=...' can also target players. And as soon as you add the 'type=Player' the command stops working. However since the @e and 'type' both seem to have the same uses neither of the two work. Running @r without a type will work. The same goes for all selectors that run at the player (supposedly).
To my knowledge this should not happen. The player most likely gets unloaded like an entity or tile entity would do as to reduce proccessing (only gets unloaded if outside of spawn chunks). However the player is an exception and can load chunks and therefore obviously load itself and other entities (more specifically in singleplayer). But the @e and/or 'type' treats it like any other entity and allows the player to be unloaded.
With further testing I noticed that it somehow affects @p, @a and @r in ways too. @p, @a and @r seem to run commands as intended due to running directly at the player? (I honestly don't know), but I just now found out that when the player becomes unloaded and attempts a command like the following, it "sorta" works.
If unloaded:
/effect @p[tag=Test] speed 1 100
The @p does work on the "unloaded player", but doesn't really behave as it should. Whilst the command does get run and the effect is applied. The speed increase is 0%. A potency of 100 would increase the FOV by a lot, but if the player is unloaded the effect is clearly applied (look at the top right corner) but the changes aren't present at all. No speed, no FOV change, nothing.
Ideally if you want to test things after reproducing the bug you should go back to the spawn chunks to be sure. The world spawn should be around: 0 6 0 or so.
The bug appears to happen with tags, score and none at all so it feels like an issue with @e. Works in 1.8, the player can run the commands anywhere without getting any errors like "Player not found".
Here's a vid: https://www.youtube.com/watch?v=x0JeQQ0X2Mw&feature=youtu.be
Related issues
Comments


Well sort of the same. It might be. However with this bug it's the fact that you become completely untrackable when using @e or @r[type=Player]. The bug doesn't occur until you update the player after you've entered unloaded chunks.
And in this case the update requires the player to move at least 100 blocks. If they move 50~ blocks the player will still be trackable due to not being updated. Here's a vid: https://www.youtube.com/watch?v=x0JeQQ0X2Mw&feature=youtu.be I use an objective here but the same happens regardless of objective, tag or any of that. Then there's the fact that you can apply eg: speed, but it doesn't actually modify the player in any way.

ok, I'm going to link it as duplicate and further mention the vid, etc
I'm just going to mark this as relates to MC-92916, it's a long description and I'm not fully following what you're saying, but I do notice you teleport to unloaded chunks