Xyzzy_

Still in 1.19.4. I think this is a worthwhile fix to creative mode, as you can just break and place the cauldron again if you want to change its contents.

Wish we could get an explanation as to why this won't be fixed. It seems like the developers are trying to make redstone more accessible given all the recent additions in 1.19.4 and the 1.20 snapshots, yet longstanding features like hoppers and redstone dust are still non-deterministic and locational (MC-11193). The behavior discussed in this report only exacerbates the problem, and, to reiterate cubicmetre's comment, makes redstone more frustrating and unapproachable for folks unaware of these quirks. I'm certain that I'm not alone in thinking this - as indicated by the duplicate reports, it's easy to accidentally create a hopper setup that behaves differently after a reload.

Resolving non-deterministic behavior is a completely separate issue, but at the very least I'd hope that this ticket is reopened and the problem corrected if there are no plans to fix hopper locationality any time soon. Perhaps there is some way to insert tile entities into the HashSet upon placement instead of upon unloading, which would fix this problem as I understand it. Either way, I don't think these kinds of issues should be ignored, if not for the sake of more consistent redstone builds then for a slightly less steep redstone learning curve.

Looking at other reports on hoppers has led me to believe that this behavior is a duplicate of #MC-96709. Tile entities are ticked in the order you placed them until the world or chunk is reloaded, after which the game defaults to using a hash set to determine tick order. However, this system is locational, meaning that hoppers will behave differently depending on where they're placed (the most common symptom of this can be seen with a simple horizontal hopper line - send items through, lock the hoppers, and some will be empty). I imagine if you rebuilt any of these setups in separate locations, you'd eventually encounter pickup behavior inconsistent with the testing results.

I don't know if this bug fully explains why the results vary depending on the speed of the minecart, though it probably has more to do with where the item entity is placed within the world after the minecart is destroyed. In my testing, tile entities and item entities with a hitbox that extends over two hoppers will respect the placement order before a reload.

Can confirm this behavior in 1.19.3, though it does appear to be affected by the speed and/or position of the hopper minecart.

With the setup above, the end result changes depending on which rail the cart is initially placed. This is also the default behavior after reloading, with the right cart ending at the left hopper and vice versa. However, if the hopper order is reversed, the cart item will be picked up by the left hopper, regardless of the rail on which it's placed, until the world is reloaded.

However, replacing two of the powered rails with regular rails as shown in the second setup makes the item pickup behavior consistent for this specific design. It's also consistent even if the order of hopper placement is inverted. After reloading, the game defaults to the right hopper.

I'll add that I have only ever noticed this behavior when using empty hopper minecarts. In my testing, if the hopper minecart contains even one item, the left hopper always picks up that item and the right always picks up the minecart item, even if the left hopper is placed first.

After more testing, it's also worth noting that these results vary depending on the type of minecart used. Using the first setup with chest minecarts doesn't differ from any outcomes seen with hopper minecarts, but minecarts alone always respect the order of the hopper placement, e.g. if the left hopper is placed first, it will always pick up a regular minecart (defaults to right hopper after reload). This setup doesn't allow me to test furnace minecarts though, presumably because they travel the slowest of all minecart variants, so further testing may be required.