I was experimenting with working around the currently known problems with entities and structure blocks by using an auto:1b "one command creation" embedded inside of the structure and then detecting the direction. The direction detection relied on executing on an armor stand to test for a Data Structure Block that has a certain metadata tag (yes, I tested this without /stats and it successfully found the block at the location).[ -However, the "/stats entity @e[type=ArmorStand,r=1] set SuccessCount @e[c=1] Test" did not work (yes, I did the required preparation such as creating the objective and setting the score to 0. I feel that this summary is getting too long, but setting the "selector" at the end to my username DOES work. This isn't just an error by me, because other custom crafting modules that rely on /stats entity have broken too).

What I expected to happen was...:
Generalization: When I used /stats entity to refer to another entity by selector, the other entity would have the proper score set.
When I ran the commands listed later, the spawned armor stand would have the tags "Wall", "WallFound", and "WallSouth."

What actually happened was...:
Generalization: When I used the /stats entity command to refer to another entity by selector, the score remained 0 even though the command actually succeeded.
When I ran the commands listed later, the spawned armor stand still had the tags "Wall" and "WallNotFound."

Steps to Reproduce:
0. Keep in mind that I had my problems on a SERVER. So if you cannot reproduce it on singleplayer, try a server. This problem affects both singeplayer and multiplayer. If you are not following the other steps, make sure you try to reproduce this with "/stats entity @whatever ... @whatever ...". I am fairly certain that /stats block works, and /stats entity with a player works. If @p and @a work, try @e[c=1].
1. For this example, we will use absolute coordinates (except when /executing) for simplicity. For items from 2 until 10, enter the commands into command blocks that execute in consecutive order.
-2. /setblock 0 0 1 structure_block 3

{mode:"DATA",metadata:"TEST"}

-
3. /scoreboard objectives add WallTest dummy
-4. /summon ArmorStand 0 0 0

{Tags:["Wall","WallNotFound"]}

-
5. /scoreboard players set @e[tag=Wall] WallTest 0
6. /stats entity @e[tag=Wall] set SuccessCount @e[c=1] WallTest
-7. /execute @e[tag=Wall] ~ ~ ~ /testforblock ~ ~ ~1 structure_block 3

{mode:"DATA",metadata:"TEST"}

-
8. /execute @e[tag=Wall,score_WallTest_min=1] ~ ~ ~ /scoreboard players tag @e[c=1] add WallSouth
-9. /scoreboard players tag @e[tag=WallNotFound] remove WallNotFound

{Tags:["WallSouth"]}

-
10. /scoreboard players tag @e[tag=WallSouth] add WallFound
11. Now, run the commands in consecutive order and run /entitydata @e[tag=Wall]
12. If you look in the "Tags" section, you will see "Wall" and "WallNotFound", even though the block did exist with the proper data and the tags should have said "Wall", "WallFound", and "WallSouth." Further, the entity has a WallTest score of 0, instead of 1.

Simplified steps to reproduce:
1. Summon some entity named "TEST"
2. Create an objective TEST
3. Run /scoreboard players set @e[name=TEST] TEST 0
4. Run /stats entity @e[name=TEST] set @e[c=1] TEST
5. Run /scoreboard objectives setdisplay sidebar TEST
Now there should be a UUID with a score of 0 on the right. Watch this.
6. Move the entity to a grass block and run "/execute @e[name=TEST] ~ ~ ~ /testforblock ~ ~1 ~ grass"
7. Notice that the UUID stays at 0 instead of increasing to 1.
8. Run /scoreboard players set @e[name=TEST] TEST 1
9. Move the entity to some block that isn't grass.
10. Run /execute @e[name=TEST] ~ ~ ~ /testforblock ~ ~-1 ~ grass
11. Notice that the score is still 1, despite the command being unsuccessful.
Appendix: Running "/stats block X Y Z set SuccessCount @e[name=TEST,c=1] TEST" on a command block with any command, even "/execute <whatever>", will update the score correctly. However, this of course does not apply to command block minecarts, and /stats block can only be used with one entity per command block.

After testing in other cases, I have figured out that my problem is that @e[c=1] does not work using /stats entity. @e[tag=TEST,c=1] or @e[type=ArmorStand,c=1] as the target selector still works. I've tested this in singleplayer and multiplayer from 1.9.4 to 16w21b.

What I expected to happen was:
When I ran /stats entity @e set SuccessCount @e[c=1] TEST, /scoreboard players set @e TEST 0, and /execute @e ~ ~ ~ /say TEST, all entities' scores would be set to 1.

What actually happened was:
When I ran the above commands, the scores did not change at all.

Steps to reproduce:
1. Summon an ArmorStand
2. Run /scoreboard objectives add TEST dummy
3. Run /scoreboard player set @e[type=ArmorStand] TEST 0
4. Run /stats entity @e[type=ArmorStand] set SuccessCount @e[c=1] TEST
5. Run /scoreboard objectives setdisplay sidebar TEST
6. Run /execute @e[type=ArmorStand] ~ ~ ~ /say TEST MESSAGE
7. See that the scores stay at 0, even though the command succeeded.
8. Run /stats entity @e[type=ArmorStand] set SuccessCount @e[type=ArmorStand,c=1] TEST
9. Run /execute @e[type=ArmorStand] ~ ~ ~ /say TEST MESSAGE
10. See that the scores update, even @e[c=1] and @e[type=ArmorStand,c=1] would have targeted the same entity in this case.

I am sorry if this is a duplicate, as it seems to have been around for a while. I searched for about an hour and found nothing like this bug.