I have a new development: The circuit that proves torches work as intended does not work in the Java (PC) version of the game. The components used are all currently implemented in the Pocket/Windows 10 edition of the game. The Java circuit is in both screenshots, on the left of SideBySide.png and the main feature of Javacircuit.png. The java circuit reacts differently than the windows 10 version, proving that torches do not line up with one tick.
Edit: I have tested a one- tick PC redstone torch with an old style two-torch repeater. It seems that the NOT gate is reacting to the torch much like the redstone wire in Pocket Edition, in that the "repeater" does not respond to the visibly powered torch and connected wire
Edit: Sadly, i cannot add a screenshot, as the moment of all three things happening at the same time is very small, and would require very precise timing to capture.
I have noticed this in Windows 10 edition: the player cannot reach as far in two directions as the opposites of those two.
Edit: I did not mention that this was in creative mode.
I have replicated your circuit for torch taking one tick to turn off, but instead of a side- block torch, I substituted it for a top of block torch, and the results remained the same. I ran this in order to test whether or not the behavior of torches differed based upon their orientation, as with MCPE-11855's oddities. Screenshot: Replicatedcircuit.png
I can confirm that the door does make the opening sound, as well as the closing sound on WIndows 10 64 bit
With your torch and-gate experiment, would the AND gate not add a delay to the circuit? I feel that if you added torches of any kind to the circuit, it should cause the pulse to be thrown out if too short, due to it not satisfying the delay. With your circuit as-is, the torches could be adding up to a one tick delay from the existing, incorrect delay that you proved exists, but is less than one tick in the Door test.
Will do, many, many apologies for duplicating a ticket.
I'm rather interested to see an example of this, because I think it would be interesting to see if this relates to any bugs I have reported (a few redstone torch bugs).
The odd thing is, with the Burnout torch clock (which I will add once I figure a way to) the delay seems present, even to a point of too much of a delay, as the torches alternate so evenly that the top wire will stay continuously powered throughout the cycles. More torches added just continue their neighbor's activity
Edit: I actually may make this a separate report after checking to see if it has been reported before or not.
Edit: I have created a separate report for this issue labeled MCPE-11906
(scorethrough)To respond to your comment PHO, if i'm not mistaken, Redstone torches do introduce a delay of one tick to any circuit that they are added to, since they definitely aren't instantaneous (such as Redstone wire). I will soon put up a specific test/example(/scorethrough)
Edit:
A minor possible oversight: Since redstone torches add a delay of one tick to circuits, how would the clock circuit be a one-tick clock? with four torches, the delay would be 4 ticks. This would mean that the pulse of the redstone dust would have to overcome the threshold of four ticks in order to carry through the clocks. Either the system is Very broken, or I feel that we might have stumbled a bit with the one-tick notion (the latter being more likely)
With the redstone lamp being used to show the states of the redstone wire, I found it to be inaccurate, as redstone lamps do not update within one tick. When replicating this with a door in place of the lamp (since doors are proven to detect very short pulses), I found that the door made no sound, did not interact differently, and did not visually change. This addresses a downfall of RedSIdeOn and BlueSideOn.