Entity selectors within a "score" expression in a JSON text behave unexpected, when combining /execute with /data merge.

Behaviour can be reproduced as follows:

1) prepare function with following lines (called test.mcfunction, see attached file):

• scoreboard objectives add test_value dummy
• scoreboard players set @s test_value 10
• setblock ^ ^ ^10 minecraft:sign
• tp ^ ^ ^10
• execute at @s run data merge block ~ ~ ~ {Text1:"[ {\"text\":\"@s: \"}

  ,{\"score\":{\"name\":\"@s\",\"objective\":\"test_value\"}}]"}

• execute at @s run data merge block ~ ~ ~ {Text2:"[ {\"text\":\"0.1: \"}

  ,{\"score\":{\"name\":\"@e[distance=..0.1,type=armor_stand,sort=nearest,limit=1]\",\"objective\":\"test_value\"}}]"}

• execute at @s run data merge block ~ ~ ~ {Text3:"[ {\"text\":\"20: \"}

  ,{\"score\":{\"name\":\"@e[distance=..20,type=armor_stand,sort=nearest,limit=1]\",\"objective\":\"test_value\"}}]"}

2) place an armor_stand

3) run function on armor_stand via following command:

• /execute as @e[type=minecraft:armor_stand,sort=nearest,limit=1] at @s run function <namespace>:test

Expected behaviour:

1. objective test_value is created
2. test_value is set to 10 for the armor_stand
3. sign is placed 10 blocks in front of armor_stand
4. armor_stand is teleported to sign
5. First line on sign should now be set to "@s: 10"
6. Second line on sign should now be set to "0.1: 10"
7. Third line on sign should now be set to "20: 10"

Found behviour:

1.-4. As expected

5./6. "score" doesn't seem to find the armor_stand, although the command /data is called by the armor_stand from current position (via /execute) => only the "text" is written in the first two line, no "score"

7. As expected

It seems like the @s-selector isn't properly set during evaluation of the JSON-text. Even when the player, which calls the original function, himself possesses a valid value for test_value, no "score" is expressed.

It further seems like the @e-selector uses the original position of the armor_stand, instead of the current position, contrary to what would be expected when using the /execute at @s command.