This is a very specific bug and took lots of testing to reliably discover what the problem is and find a pattern in the behaviour. However, I am no closer to discovering the reason why this happens.

Set up steps:

1. Build a standard fill clock with the following commands:

   fill ~ ~1 ~ ~4 ~1 ~ minecraft:stone (on bottom)
   fill ~ ~-1 ~ ~4 ~-1 ~ minecraft:redstone_block (on top)
   

2. Create a score called Test and set it to the sidebar.
3. Spawn an armor stand.
4. Along the fill clock, place the following four commands, in ascending x order (does not necessarily have to be x, just ensure that the order the commands are run is preserved)

   tp @e[type=ArmorStand] @p
   scoreboard players set @e[type=ArmorStand] Test 0
   execute @e[type=ArmorStand] ~ ~ ~ scoreboard players set @e[type=ArmorStand,r=1] Test 1
   tp @e[type=ArmorStand] ~-8 ~ ~
   

   If one tries to run this fill clock, the expected behaviour would be for the ArmorStand to constantly have a Test score of 1 at the end of the cycle, regardless of the player's position. This expected result occurs if the final /tp command is omitted. However, if left in, very unusual behaviour occurs.

With that particular /tp command included, if the player is positioned between the internal chunk x coordinates 3 and 8, the execute command will fail and Test will be 0. If the player positions themselves from 8 to 15 or 0 to 2, Test will be 1 (i.e. expected behaviour)

A pattern arises where the relative teleport value becomes the chunk x coordinate which will provide the upper end of the failure interval. i.e.
tp @e[type=ArmorStand] ~-9 ~ ~ will cause the /execute to fail from 3 to 9, tp @e[type=ArmorStand] ~-15 ~ ~ will cause the /execute to fail from 3 to 15, tp @e[type=ArmorStand] ~-17 ~ ~ will cause the /execute to fail from 3 to 1 in the next chunk, and anything larger than -19 will cause the execute to fail regardless of the player's position.

If a formula were to be applied to this, the execute will fail within the range of 3 to (-tpX % 16). To summarise, for negative tpX if -tpX is smaller than 3, the /execute will always succeed and if larger than 19, will always fail.

This same issue also occurs on all other coordinate axes and also occurs if positive relative teleports are applied, however the range will instead be ((15-tpX) % 16) to 12, as it instead hangs at the upper end (15 - 3) of the chunk range and extends backwards from there.

Modifying the r value in the /execute command to be larger will ultimately have a threshold for each tpX value at which the /execute will no longer fail, however I have as yet not been able to find a pattern which correlates.

Obviously this behaviour is completely unintended and can cause major failures in more complex command systems. Hopefully my explanation is not too convoluted, as I mentioned at the beginning this is a very specific bug but has major consequences.

I have also attached four pictures. The first shows my setup. The final three show the results with a /tp command of tp @e[type=ArmorStand] ~-8 ~ ~. You can clearly see that at internal chunk x coords of 3 and 7, Test is 0 (/execute failed) and at 8, the /execute has succeeded.

Thanks very much and hope this was helpful, Klep

EDIT: Here is a more generalised case in which a similar arrangement will fail for no particular reason.

tp @e[name=Test1] @e[name=Test2]
say @e[r=1]
tp @e[name=Test1] @p

Create two armor stands named Test1 and Test2. Test2 should be situated directly above the second command block. Put all these on a fill clock and ensure they are in ascending order as usual.

While one would expect that the say command should always report that Test1 and Test2 are in the same position, this is not the case and will fail if the player is outside a certain range of Test2. Changing r to be bigger will modify that range to be large, but this has no conceivable pattern.

It almost seems as if the second teleport cancels the first teleport when the player is too far away?

I'd appreciate if mods could help me clean up this report to be more clear.