/execute as @a at @s anchored eyes positioned ^ ^ ^1 run particle flameWith this command, flame particles will spawn in front of the player every time.
/execute at @a anchored eyes positioned ^ ^ ^1 run particle flameBut with this command, flame particle will spawn at the feet of player but will still spawn in the direction player is looking.
This is because "positioned ^ ^ ^1" take location context (at @a) as an input and display it properly while "anchored eyes" does not.
Because "anchored eyes" affect the execution location of the command I think it should follow the same behavior as "positioned ^ ^ ^1"
Comments 2
anchoring would not make sense when the position is not relative to an entity, thus having no eye or feel levels.
The same thing could be said for "execute positioned" isn't it?
"positioned ^ ^ ^1" would not make sense when there is no looking-direction of an entity. but that is solved by storing the rotation in the location context via "execute at" instead of executor context and provide a default value when no entity is supplied.
I'm under the impression that anything that changes execution location should follow "execute at" subcommand. So, anchoring would still make sense when making it relative to "execute at".
This is, for all intents and purposes, working as intended. This is best described through the wiki description:
Regardless at what position the command is being executed, anchoring is performed relative to the executor. This is done to allow for complex scenarios of things facing different things. Equally so, anchoring would not make sense when the position is not relative to an entity, thus having no eye or feel levels.