NinjaPigeonHit

Yes, this issue still occurs

Yes, this still affects the current version

Updated the bug report.

This issue can also be seen if you power droppers with a redstone dust line, then power them with observers, both with no delay between activations, the update order will be different. An easy visualization of this is to do the say command in command blocks, and have them ordered to say numbers 1-15. Then, power these command blocks with a redstone dust line soft powering them. The numbers will appear in a certain order. Next soft power the command blocks with observers, no delay in between each observer. The order of the list of numbers the commands blocks say are different when observers are used. This issue is also present with droppers and other consumers.

To prevent the moving block from being movable in gametick 4, in the proposed action-observation tick system, there could be a pseudo update order created for moving blocks, where a moving block always updates before a piston does, which would allow the movingBlock to be pushed reliably on gametick 2. Also MCPE-15793 is similar behavior to the java "player input bug" that was marked Won't Fix, there is currently another bug report about the "player input bug" that is still unresolved, but the initial one was Won't Fix. So this bug is java parity. Also, could MCPE-15793 bug not be fixed by action ticks being every tick, almost like the redstone system in java, instead of an action-observation tick system.

There was a problem I saw in your video, in the clips where you showed oak being grown next to the logs and pistons, that is not oaks normal growth requirements, it is a random chance that they will grow with those blocks next to them, but if their actual growth requirements are met, it will take on average 6 bonemeal attempts with dispensers, or 1 by the player. Oak growth requirements are the same as every other tree, except oak has a chance to become a large oak tree, and has a random chance of growing next to a tower of blocks that aren't dirt air or leaves, like shown in your video. The growth requirements is a 5 by 5 crown, with a 3 by 3 base, this is the same for all small tree types, those being oak, spruce, birch, jungle, and acacia. There is no inconsistency between growing requirements beside oaks random chance at growing when next to a tower of blocks, but when next to a tower of blocks, it normally blocks a lot of growth attempts. Besides those problems, this would also be disparity with the java version.

These two bugs are different, this bug is regarding java parity with tree growth requirements, and logs blocking tree growth. The other "bug" that this is a "duplicate" of is suggesting changing all tree growth requirements, to be a 1 by 1 area, which is disparity, and far different from what this bug is asking