"execute store" on "double" data types uses only 'float' rather than 'double' precision in intermediate scale calculation

go into a world in creative, fly

/scoreboard objectives add ReturnX dummy
/tp @p 2097150.3 200.0 0.0
/execute store result score @s ReturnX run data get entity @s Pos[0] 1024.0
/summon area_effect_cloud ~ ~ ~ {Duration:1000,Tags:["return_loc"],Rotation:[20f,20f]}
/execute store result entity @e[limit=1,tag=return_loc] Pos[0] double 0.0009765625 run scoreboard players get @p ReturnX
/execute as @e[limit=1,tag=return_loc] at @s run tp @p ~ ~ ~

Expected: press F3 and see that the player's coordinate still ends in ".3"
Actual: player's coordinate now ends in ".25"

The behavior is what one would get if the intermediate 'scale factor' in the store were using single-precision rather than double-precision floating point, which I expect is the source of the bug. (double-precision has plenty of significant digits to recover the precise value)

Implications for gameplay: you can use this technique of storing a player's coords in the scoreboard to tp them somewhere and then return them to their exact position. However, due to the precision bug, players standing next to a wall get returned to a slightly different position and suffocate in the wall.

EDIT

Here is a simpler-to-understand repro

go into creative, fly, run

summon pig ~ ~ ~ {NoAI:1b,Tags:["piggy"]}

then run a function:

scoreboard objectives add Score dummy
scoreboard objectives setdisplay sidebar Score
tp @p 1.23456789012345 200 0
execute store result score @p Score run data get entity @p Pos[0] 1000000000.0
execute store result entity @e[tag=piggy,limit=1] Pos[0] double 0.000000001 run data get entity @p Pos[0] 1000000000.0
execute store result score @e[tag=piggy,limit=1] Score run data get entity @e[tag=piggy,limit=1] Pos[0] 1000000000.0

Expected:
both guys have score 1234567890
Actual:
pig has score 1234567880

The 1234567880 wrong result is what you get when doing a 32-bit (single-precision) float calculation, whereas the 1234567890 correct result is what you get when doing a 64-bit (double-precision) calculation. And Pos[0] is a double, and called out as "double" in the command.