The bug

Unlike Java Edition, Bedrock's implementation of /schedule attempts to save some context. This is great, except for a few issues.

delay:
/schedule delay does not save context at all. In this respect, it works nearly the same as Java Edition. The sender is discarded and replaced with the server, and the position is discarded and replaced with the world origin (0,0,0). (This is where Java differs slightly, defaulting to world spawn instead).

By itself, this is acceptable, but it's inconsistent with on_area_loaded, which may be confusing.

on_area_loaded:
In 1.16, on_area_loaded also discarded context, unless the requested area was immediately loaded, in which case the command ran synchronously with context. In 1.17, context is preserved in both cases. However, it does not work properly in two situations:
1. The context entity dies before the schedule triggers
2. The context entity moves before the schedule triggers

In the first situation, the command simply aborts!! This is obviously a huge problem, since it requires you to keep your senders alive and loaded for the duration of your schedule, otherwise the function just won't ever run! This was not a problem in 1.16.

The second situation has a more minor problem. The scheduled function will run at the specified coordinates, relative to the sender. This is a similar issue to MCPE-124890; the function should run at the position it was originally scheduled, with the ability to explicitly re-sync by using another execute in the function itself.

How to reproduce

I have provided a world download that provides 12 test cases for the /schedule command. Each one prints both the sender and the coordinates that the function ultimately runs at. The test cases are as follows:

delay:
Runs a /schedule delay command. All of these tests have identical results and are marked yellow for this reason. All context is discarded, replacing the sender with the server and the coordinates with (0,0,0).

• block: Command block sender.
• alive: Entity sender.
• dead: Entity sender. The entity is killed before the function triggers.
• coords: Entity sender. Hardcoded coordinates are specified.

loaded area:
Runs a /schedule on_area_loaded command, where the specified area is already loaded. When this is the case, Bedrock runs the function synchronously. For this reason, there's no test with a dead entity. All of these tests successfully maintain sender and coordinates.

• block: Command block sender.
• alive: Entity sender.
• coords: Entity sender. Hardcoded coordinates are specified.

unloaded area:
Runs a /schedule on_area_loaded command, where the specified area takes time to load. These tests have differing results. Note that in 1.16, all of these tests discard context, running identically to the delay section above. In 1.17, the results are as follows:

• block: Command block sender. Successfully maintains sender and coordinates.
• alive: Entity sender. Successfully maintains sender and coordinates.
• dead: Entity sender. The entity is killed before the function triggers. The function never runs at all, the game prints "The origin needed to execute this function was invalid."
• coords: Entity sender. Hardcoded coordinates are specified. Successfully maintains sender and coordinates.
• moved: Entity sender. The entity is moved after scheduling the function, but before triggering it. Successfully maintains sender, but uses coordinates of the final position of the entity instead of its original position.

Summary

To sum up, there are three issues with schedule context:

• delay always discards context
• on_area_loaded reevaluates coordinates after the fact a la MCPE-124890
• on_area_loaded aborts entirely if the sender is unloaded or removed, new to 1.17

I can split this into three separate tickets if that would be most helpful, but I wanted to at least present this as a conclusive test suite for which behaviors are working fine and which have problems.