This issue isn't particularly easy to describe with just words, so my explanation will consist primarily of commands and pictures.

Consider this function, which I will refer to as "function1":

#Creates an 8x8 grid of armorstands
summon armor_stand ~ ~-0.5 ~2 {CustomName:"{\"text\":\"Bug1\"}",NoGravity:1}
execute as @e[type=armor_stand,name=Bug1] at @s run summon armor_stand ~4 ~ ~ {CustomName:"{\"text\":\"Bug1\"}",NoGravity:1}
execute as @e[type=armor_stand,name=Bug1] at @s run summon armor_stand ~2 ~ ~ {CustomName:"{\"text\":\"Bug1\"}",NoGravity:1}
execute as @e[type=armor_stand,name=Bug1] at @s run summon armor_stand ~1 ~ ~ {CustomName:"{\"text\":\"Bug1\"}",NoGravity:1}
execute as @e[type=armor_stand,name=Bug1] at @s run summon armor_stand ~ ~ ~4 {CustomName:"{\"text\":\"Bug1\"}",NoGravity:1}
execute as @e[type=armor_stand,name=Bug1] at @s run summon armor_stand ~ ~ ~2 {CustomName:"{\"text\":\"Bug1\"}",NoGravity:1}
execute as @e[type=armor_stand,name=Bug1] at @s run summon armor_stand ~ ~ ~1 {CustomName:"{\"text\":\"Bug1\"}",NoGravity:1}

#Gives each armorstand a Bug score equal to the number of armorstands within a 1.5 block radius of it
scoreboard players set @e[type=armor_stand,name=Bug1] Bug 0
execute as @e[type=armor_stand,name=Bug1] at @s run scoreboard players add @e[type=armor_stand,name=Bug1,distance=..1.5] Bug 1

#Represents Bug score with blocks
execute as @e[type=armor_stand,name=Bug1,scores={Bug=9}] at @s run setblock ~ ~5 ~ diamond_block
execute as @e[type=armor_stand,name=Bug1,scores={Bug=6}] at @s run setblock ~ ~5 ~ gold_block
execute as @e[type=armor_stand,name=Bug1,scores={Bug=4}] at @s run setblock ~ ~5 ~ iron_block

This function creates an 8x8 grid of armorstands, then gives each armorstand a Bug (dummy scoreboard objective) score equal to the amount of armorstands within a 1.5 block radius, including itself, and represents its score above it with a specific block. When run, this is the expected result (and this is the result you get):

Everything works fine with this method. However, if we alter the way that the armorstands are summoned, we get a rather unexpected result.

Consider the following function (which is actually three separate functions), which I will refer to as "function2":

#Summons an initial armorstand
summon armor_stand ~2 ~-0.5 ~2 {CustomName:"{\"text\":\"BugS\"}",Invisible:1,NoGravity:1}

#Summons number of armorstands sideways (width) equal to Size
scoreboard players operation @e[type=armor_stand,name=BugS] Size = #Size Size
function bug:width

#Summons number of armorstands lengthwise (length) equal to Size
execute as @e[type=armor_stand,name=Bug] run data merge entity @s {CustomName:"{\"text\":\"BugS\"}"}
scoreboard players operation @e[type=armor_stand,name=BugS] Size = #Size Size
function bug:length

#Changes the name of all armorstands named "BugS" to "Bug"
execute as @e[type=armor_stand,name=BugS] run data merge entity @s {CustomName:"{\"text\":\"Bug\"}"}

#Gives each armorstand a Bug score equal to the number of armorstands within a 1.5 block radius of it
scoreboard players set @e[type=armor_stand,name=Bug] Bug 0
execute as @e[type=armor_stand,name=Bug] at @s run scoreboard players add @e[type=armor_stand,name=Bug,distance=..1.5] Bug 1

#Represents Bug score with blocks
execute as @e[type=armor_stand,name=Bug,scores={Bug=9}] at @s run setblock ~ ~2 ~ diamond_block
execute as @e[type=armor_stand,name=Bug,scores={Bug=6}] at @s run setblock ~ ~2 ~ gold_block
execute as @e[type=armor_stand,name=Bug,scores={Bug=4}] at @s run setblock ~ ~2 ~ iron_block
kill @e[type=armor_stand,name=Bug]

The two functions inside, bug:width and bug:length, are as follows, respectively:

scoreboard players remove @e[type=armor_stand,name=BugS,scores={Size=1..}] Size 1
execute as @e[type=armor_stand,name=BugS,scores={Size=1..}] at @s run summon armor_stand ~ ~ ~ {CustomName:"{\"text\":\"Bug\"}",Invisible:1,NoGravity:1}
execute as @e[type=armor_stand,name=BugS,scores={Size=1..}] at @s run tp @s ~1 ~ ~
execute if entity @e[type=armor_stand,name=BugS,scores={Size=1..}] run function bug:width

scoreboard players remove @e[type=armor_stand,name=BugS,scores={Size=1..}] Size 1
execute as @e[type=armor_stand,name=BugS,scores={Size=1..}] at @s run summon armor_stand ~ ~ ~ {CustomName:"{\"text\":\"Bug\"}",Invisible:1,NoGravity:1}
execute as @e[type=armor_stand,name=BugS,scores={Size=1..}] at @s run tp @s ~ ~ ~1
execute if entity @e[type=armor_stand,name=BugS,scores={Size=1..}] run function bug:length

This "function" (once again, it is actually three separate ones, but I will refer to it as one) serves the same purpose as function one. It creates a square grid of armorstands, but, unlike how function1 is fixed to be 8x8, this square has length and width equal to #Size's (a fake player) Size score (which can be set to any number). The bug:width and bug:length functions serve this purpose, creating loops to count down the Size score to create a square of the correct size. If we set the size of the square to 8x8, we would expect the same result as function one, but what we get is this:

As you can see, the top row of blocks is completely missing. The armorstands are present, but they have a Bug score of 0. They seem to have become "invisible" to the other armorstands and even themselves. They correctly added scores to the armorstands below them (otherwise the row of diamond blocks below the missing line would also be gone), yet they failed to receive the scores from those armorstands and the surrounding "invisible" armorstands.

The primary difference between function1 and function2 is the lack of teleportation in the first one. I tested multiple different ways of setting up the commands in function2 (including putting the bug:width and bug:length functions inside the main one, making it a single function), and still got the same result. The problem lies in the following two properties:

Property one: if you split up function2 into two separate functions at the line "#Gives each armorstand a Bug score..." (which splits it up into the summoning portion and the score assignment portion), then run the summoning portion in one tick and the score assignment portion in the next tick, it produces the expect result from function1. For some reason, that top row of armorstands is not "visible" until the next tick, meaning if it is run in the same tick as the summoning portion it fails to detect them.

Propery two: if you move the location of the initial armorstand in function2 (not split up) around, there are places where the correct result is produced. The three possibilities I found were a missing top layer, a missing block in the top-left corner, and the expected result (see screenshot attachment with grass background). This means the issue is also related to the chunk the entities are in. However, when moving around the initial location of the armorstand for function1, I got the correct result every time. This would suggest that summoning over multiple chunks, even in the same tick, still allows the entity to be detected, unlike with the teleportation seen in function2. Looking at the data, this bug is closely related with the two bugs found here and here. These bugs would both account for the chunk's affect on the error and the reason the error is only present in function2 (which involves teleportation), but they do not account for the fact that the only two errors present are a missing block in the top-left corner and a missing top layer. If the top two layers were in a different chunk, for instance, both of them should be missing, but it appears to still be the case that only one is missing.

Ultimately, I do not know the primary cause of this bug, but it closely tied to the two bugs mentioned above, involving the teleportation of entities into a different chunk in the same tick. It may actually be the exact same bug as one of them, but the reason it appears slightly different is the aforementioned fact that there are only two error options even when the initial position armorstand is moved all around.

This bug can be reproduced by copying the functions above and running them in a command block.

Update: Just confirmed this bug also affects version 1.12.2. I included a screenshot in the attachments, where you can see all three possible block combinations (it is the one with the grass background).