The bug

With the new /execute command syntax, setting the position to a target with the /execute at subcommand works normally in most circumstances, such as combining it with the (if|unless) entity subcommands, and it will correctly set the command's position to that target.

However, the command seemingly does not inherit the target's position in regard to finding new targets for the /execute as, /execute at or /execute positioned as subcommands; instead, it ignores the preceding at <target> subcommand and uses the command's current position. As pointed out in the comments, a second subcommand is needed following at <target> for the command to behave as expected.

Steps to reproduce

Method A

The primary goal here is to create a situation where one entity needs to be near another to succeed. I will be using an armor stand as an arbitrary position, and a fishing hook as the entity behaving as a condition.

• Set up a new world with the Upcoming Creator Features experiment enabled.
• Place down an armor stand somewhere.
• Grab a fishing rod, and cast the bobber near the armor stand, somewhere within three blocks for this demonstration.
• Stand at least three blocks away from the bobber and run this command in chat:

  /execute at @e[type=armor_stand] as @e[type=fishing_hook,r=3] run say @s
  

  → "No targets matched selector". Only returns true when you stand within three blocks of the bobber, as the parser uses your position when finding the bobber instead of the armor stand's position.

Method B

The attached behavior pack has a unit test made with GameTest using similar reproduction steps, except the armor stand is replaced with a simulated player and the fishing bobber is replaced with an armor stand.

• Make a new world with both the GameTest Framework and Upcoming Creator Features experiments enabled, or use an existing world.
• Run the following command to start the unit test:

  /gametest run new_execute_command_tests:mcpe_156283
  

  → "No targets matched selector"