HalbFettKäse

Can confirm. This is also related to an existing issue, where the game would reset a target if it shared the same size as other targets, even if the post effect relies on the target being preserved for the next frame.

This kind of preservation seems to have been an intended feature rather than an accident, since the old phosphor.json post effect that used to be part of the vanilla resource pack also made use of it and got broken in recent versions, and with the current bug, has become impossible to implement.

It should be possible for the game to automatically recognize which targets rely on being preserved from the previous frame, simply by testing which targets have passes that read from them without there existing previous passes that write to the target.

I already explained in the ticket how MC-226487 is different from the issue described here. MC-226487 judges that the unintuitive behavior of the looking_at predicate is intended, but in this ticket, the question is whether the advancements in the vanilla data pack are intended to use this unintuitive behavior.

These are separate questions, because the looking_at predicate has no explicitly stated behavior, so the unintuitive quirks may very well be intentional, while the advancements in the default data pack, which happen to use this predicate, do have explicit descriptions that contradict the behavior of the looking_at predicate that they use.

Example 4 has a wrong expected result. The function context should start at the same position for all three commands, which means that the tp @s ~ ~ ~3 at the end should be left unaffected by the previous commands.

So the expected result for Example 4 is that the player should be teleported 3 blocks south, and not have their position changed otherwise.

Can confirm that the bug seems to be fixed now. For reference, using this advancement:

{
  "criteria": {
    "do_the_cat": {
      "trigger": "player_interacted_with_entity",
      "conditions": {
        "entity": {
          "type": "cat"
        }
      }
    }
  },
  "rewards": {
    "function": "test:do_the_cat"
  }
}

gives, when tested in 1.21.1, the following result:

Since the upper torch points in the opposite direction, its local "left" should actually point into the piston that you labeled as "right". But even in that case, the behavior should still be deterministic, as opposed to the observed randomness.

Also, the same bug applies not only to torches but also to buttons. In the given setup, you can replace the upper torch with either a button that hangs on that same wall (which makes the game ignore the button's rotation and randomize the outcome), or replace that same torch with a block and place a floor button on top of that block (which makes the wire accurately respond to the button's rotation)

The bug is confirmed already so not being able to do it is unintended.

If you need information that is generally known, such as how to use the command, you can look it up on the wiki or ask on a community forum such as the subreddit or the discord server.

You should also note that youtubers as well as most community members are not official instances that receive special treatment, they have just as much access to information as you do.

Not sure, but selecting "Singleplayer -> Edit -> Optimize World" might fix it, but I doubt that it also erases the cache.

The maxHealth attribute only changes the amount of HP you are able to regenerate to. So when you set that to something lower than your current HP, the game will not remove anything as this isn't what the maxHealth attribute does.

Damaging the player by 2 HP will in this case resolve the issue and the player would not regenerate to anything above 18 HP.