Vincent Wiltschek

Read the last edit. It explains a way to replicate the bug without torches. Just instant NOT gates using pistons and repeaters.

The problem ARE 0tick pulses off pulses.

Would really like to see a working 6.7Hz CPU but I don't see how that is possible with 0tick pulses going off randomly everwhere.

Did you read the last part of the description?

Please test the bug with pistons as described in my initial report (MC-8328):
"To replicate it, OR the input of an instant NOT gate (http://youtu.be/vCsJWc7PcT0) and it's output together and attach it to another piston. Toggle the input"

Still the same. Bug not solved.

I gave one way to replicate it in the description of MC-8328.

oops, sorry.
didn't know you get a notification for every edit.

Ok but this bug right here definitely does not exist in the Pocket/Win7 Edition.

Also affects Minecraft Pocket/Win10 Edition v0.15.0 (MCPE-15391).

Yes, exactly.
Sorry for the duplicate but I could not select "Minecraft Pocket Edition" or "Minecraft for Win10" in the list of affected versions of the original issue.
If you could add it to the list for me, you could delete this duplicate issue right here.

The bug has been discussed intensively in the comments section of the original issue (the conclusion is in the original report).

Sorry, the bug does NOT exist in PE/Windows 10.
I made a mistake.
You can delete this issue.

Hold on, let me do another check.

you could always add another server command lol

but no, I agree with you, since these feedback loops can only be used for creating pulses (not logic or any function that could get destroyed), it would be better to let them pulse.

Yes, I am criticizing the random block updates and their consequences, which are 0-tick pulses because Minecaft does not update blocks in sync.
The problem is not necessarily the update order but the lack of a "buffer", meaning that Minecraft should wait until the next gametick to put all affected blocks into the next state at the same time instead of reacting successively in microintervals (whether it be to user inputs or circuit outputs). The update ordering/processing should all be done "internally" instead of directly influencing in-game behaviour.

To be clear, I am not talking about "making 0-tick pulses reliable/intuitive", so removing the direction/position dependencies and other inconsistencies. I AM talking about completely removing them from the game because a proper update algorithm does not require them...

Now, I have to say that I didn't consider instant feedback loops like the ones you posted but realize that in these cases there simply is no logical behaviour because what is supposed to happen is impossible: Due to the instant properties of pistons, the redstone should be simultaneously on and off. Saying "the piston should pulse" is just as legit in this situation as saying "nothing should happen", as is saying "the piston should turn into a derp piston".
Thank you for taking this a step further by comparing the piston inside the loop to an "external piston" and showing how there would be inconsistencies if you used micropulses in some situations as solutions to impossible tasks and got rid of them in other situations.
Because letting nothing happen even though the switch changed state doesn't make sense and because not allowing a switch to be toggled would be strange (and because inconsistencies are to be avoided), my conclusion on instant feedback loops is: The internal piston(s) should turn into derp piston(s) (lock in the current state) and the external one(s) should therefore do nothing. All this does not require micropulses.

I will add my suggestion of a server command to my original bug report, consequently the monostables you posted would not work with the "intended behaviour" option (no 0-tick pulses whatsoever), while everything remains as it is with the "unintended behaviour" option (this being the default setting).

EDIT: How pistons behave when they are retracting is completely off-topic. We are basically discussing whether or not pistons (or other mechanisms) should start retracting (in these 'special' cases) in the first place.

"Fixing" 0 tick pulses (meaning removing them where possible) is not illogical, it simply requires an actual algorithm to decide the block update order instead of just relying on random java hashsets!

Good example, Myren. The problem with the circuit you posted is not pistons reacting to 0-tick pulses but the fact that you built an instant/infinite feedback loop (basically the grandfather paradox).
There is no why any game or simulation could handle this situation correctly. In this case, you cannot avoid pulses (I mean you could just make it so that nothing is happening at all but I agree with you that this is probably not the best solution).

In every other case (where the order of events can be logically/causally assigned) 0-tick pulses can be removed.

The piston flip flops you are talking about, Dico, do not require 0-tick pulses. They work the same way with 1 (redstone) tick pulses.

And hopefully for the last time, I suggest a command that lets you decide what type of behaviour you want so that all of your circuits can remain working.

Well, we were actually talking about the same repeater designs and I really don't see where they rely on microticks (time intervals below 0.05s).
I had some different ones in mind when you mentioned microticks but I cannot remember where I saw them.

They DO completely destroy basic logic because when a piston stops receiving power and starts receiving power from a different powersource in the same gametick, it pulses.
In other words, you will have a moment where you will see the piston retracting although the redstone line was always ON!!

"As I also mentioned, it is very possible to make instant logic work right now."
Nope, not reliably. Build an instant adder and test all possible input transitions, even better, do it at operation speed (5Hz).
Of course, I'm happy to be proved wrong.

"You have to synchronize the incoming signals to solve that"
They are synced to the shortest consistent time unit of Minecraft (1 game tick).

"Apply logical thinking instead of requesting a change that makes it easier."
I'm ignoring this since you could say the same thing about builds that rely on micropulses if the situation was the other way around.

"Mojang made pistons work this way, they weren't designed to do the things they do entirely, indeed, but right now, as with diagonal powering it is too late to revert this change IMO."
"My last point: Why should we remove an awesome aspect of the game for the bigger player base (timing-centered redstoners) to make some other thing with logic-centered redstone easier?"
Once again, you are not losing anything if Mojang introduces a (server) command that can switch between the unintended and intended behaviour. There does not have to be a trade-off.

"That's not a nice trade-off."
That's your opinion.
...Maybe think about what could be done with CPUs that are more than 50 times faster than anything that has been created in Minecraft.

0-tick pulses are not what makes instant logic possible. It purely has to do with the moved block instantly becoming transparent (which is completely intended behaviour).
I know that there are some other instant repeater designs out there that somehow use microticks but they are unnecessarily complex and obviously even more unreliable.

I understand that there are a lot of applications for 0-tick pulses but unlike quasi connectivity (or other "accepted bugs") they completely destroys basic logic (in other applications).

Minecraft time is designed to be quantized and the smallest interval is supposed to be 0.05s.
Therefore, Minecraft should also be able to handle simultaneity, it cannot do that at the moment.
If you want to actively bypass these design principles and you need micro-intervals to get something to work, it should not make other ("legit") contraptions impossible/unreliable, especially when these contraptions will lead to much more advanced technologies than piston doors (just imagine what you could do with a 5Hz CPU!).

...My suggestion would be a gamerule that can turn micropulses on or off so that everybody is happy.

Ok, this bug is an exception then because it is most probably caused by MC-8328 (0-tick pulses) that in turn seems to be caused by the fundamentally illogical block update 'algorithm' of Minecraft that is unable to properly handle simultaneity.
If there is one bug that won't get fixed 'accidentally' it's MC-8328 (and therefore MC-9955, too).

Why? It affects every version until it gets resolved. Simple logic.
No point in creating a list of 20 different versions.

It is.

Why is it marked as resolved? Could you reopen it?
Not that the bug is that important, I'd rather see MC-8328 fixed.