distance selectors use information from prior entity locations, giving surprising results

I can imagine the game has always been like this (not a regression), but I've not gone back and tested 1.12. EDIT it is the same back in 1.11.2, I'd bet a lot that it's always been this way.

summon minecraft:armor_stand ~ ~ ~ {NoGravity:1b,Tags:[AS1],CustomName:"\"AS1\""}
execute at @e[tag=AS1] run summon minecraft:armor_stand ~ ~ ~48 {NoGravity:1b,Tags:[AS2],CustomName:"\"AS2\""}

We have 2 armor_stands, 48 block apart. Then make an impulse and chain command blocks (2-long chain) with

execute as @e[tag=AS1] at @s run tp @s ~ ~ ~48
execute at @e[tag=AS1] as @e[type=armor_stand,distance=..1] run say hi

Activate it.

I think for most folks, the expected outcome is

EXPECTED

both AS1 and AS2 say hi

ACTUAL

only AS2 says hi

ANALYSIS

If you run the final command from the console (or from another command block) in a subsequent tick, you get the expected output.

I think the issue is that "distance=..1" will "cull chunks" when searching for entities, and "the chunk an entity is stored in" is always "the chunk it was positioned in at the start of the tick". So even though AS1 moved 48 blocks to a different chunk in the impulse command block, the game still has its entity stored in the old-position chunk, which is why distance=..1 does not find it 'this tick', but does find it in future ticks (after game processing has seen that the position changed and the chunk-storage for the entity also must change).

I think it's ok if this bug is WAI or WontFix, as it might be a hefty efficiency penalty to make it work properly. But it would be nice to have an 'official ruling'.

(I have not tried with dx/dy/dz, but I suspect a similar thing can happen.)