vktec

I think it was a joke

This is almost definitely WAI. If it's not, I wish it was because it's incredibly useful.

Sorry, forgot to check back on this. What I'm referring to is that piston heads have a hitbox that slightly protrudes past a 1x1 block space (to connect with the piston base) which in current stable versions will remain while the piston retracts, clipping through the back of the block, which can push entities back from the piston.

You can test this by pushing yourself up against the back of a sideways piston with a redstone block above and then removing the redstone block - in stable versions, you'll be pushed backwards slightly, whereas in snapshots you won't.

This is not a bug, and occurs in 1.15.2 as well. This happens because of hopper update order, which is effectively random. Also, observers will not detect inventory changes in Java edition.

Further testing in a server I'm part of indicates this bug only occurs for 2-tall mobs - creepers, for example, can spawn with scaffolding in their head. This suggests to me that the mobs are (incorrectly) colliding with the top of the scaffolding.

That is incorrect. Mobs will spawn inside doors, with trapdoors or string inside their heads, etc.

The spawning algorithm requires a non-full block at foot and head height, as well as that the entity to be spawned will not collide with anything.

Experiencing this on 1.15.1-pre1 as well

Just to make sure I wasn't being an idiot, I wrote a mod using my suggested fix. It seems to work fine, but I've not done particularly extensive testing. If anyone feels like playing with it, the code is here: https://github.com/vktec/wire-order-fix

A JAR file for 1.14.4 Fabric can be downloaded from here if you don't feel like compiling it yourself: https://github.com/vktec/wire-order-fix/releases/tag/0.1.0

I think you may be out of date. updatePowerStrengthImpl is the only place where toUpdate is modified, and performs no recursive calls that I can see. updatePowerStrength clears toUpdate directly after calling updatePowerStrengthImpl which, as you say, makes the set pointless.

There may be a hidden recursive call I'm missing, however.

Perhaps I'm misreading the code, but as I see it, updatePowerStrength and updatePowerStrengthImpl could be merged into one method, with toUpdate being a local variable (which would be slightly slower than having it as a field, my point is just that it could be done).

Since the blocks which get added to toUpdate are the same every time, and none of those will be the same as any other (they're the redstone wire block and the 4 blocks in each cardinal direction from it), I see no reason to store them in a HashSet at all.

Again, I may well be reading the code wrong and it's much more complex than I think.

One simple method to make redstone wire update in a more predictable manner would simply be to stop using the `toUpdate` field of `net.minecraft.world.level.block.RedStoneWireBlock`: instead of adding the positions to be updated to a set which is later iterated over and then cleared (note that the only uses of `toUpdate` are in `updatePowerStrength` and `updatePowerStrengthImpl`), simply update the positions as they are found - call `Level.updateNeighborsAt` once with the position of the dust, then once per Direction, utilizing the loop in `updatePowerStrengthImpl` that currently adds the positions to the `toUpdate` set.

I could create a patch showing these changes, but I'm not sure how useful it would be since it's deobfuscated code, and am also unsure about whether or not it violates the EULA

I'd urge you to reconsider on the "works as intended" resolution. This was the one thing, other than the possibility of not sticking to slime, that made honey interesting to me. If both of these are "works as intended", honey is fairly uninteresting as far as redstone is concerned.

Still getting this with cauldrons in 1.14.4