Introduction

In 17w16a the command block mechanics were changed to now traverse chains live instead of scheduling the chain command blocks for the next tick (see this comment).

The claim that this will "revolutionize command blocking" is a pretty big one, so let me explain why I think that this is the case.

New possibilities

Live changes to command block chains / Live switches

As described in slicedlime's video "Advanced Commands Tutorial – Instant-off, If-Else and Minecraft 1.12 Chains" you can now change a command block chain in the same tick it is running and the changes will affect the chain. This used to not be the case but instead was only possible one tick delayed.

This change is a pretty important one and allows for example more efficient command block contraptions. Image you have multiple command blocks which are only required if a certain condition is met. Thanks to this change you can now skip these command blocks in the same tick if the condition is not met saving a lot of unnecessary command executions.

Loops

Despite the fact that the developers tried to prevent loops, they are possible with some tricks.

It looks like you can achieve them by changing the chain command blocks which need to run a second time. A "simple" (but expensive) way to do this is to /clone ... replace move them.

Here is a quick demonstration: http://ift.tt/2pL4FrJ
The gif is showing a loop which prints a score of the player (which is set to 500 at the beginning) and then reduces it by one each iteration. To show that this is happening all in a single tick a repeating command block is placed next to the redstone block printing "Tick" each tick.

This creates so many possibilities; it make for example owner detection possible. Owner detection is a pretty important part for most multiplayer maps. Imagine someone wants to create a paintball game and somehow has to track which snowball was thrown by whom. This can be done by giving the players an incrementing ID score and then giving the snowball the same ID value. The problem with this is that you cannot use dynamic values in selectors, but only static ones. Therefor you could test the ownership for one player at a time by subtracting their ID value from the ones of the snowball and then execute on the snowballs with value 0 since they had the same ID value as the player. With loops you can still only do this one player at a time but continue that in the same tick until all players have been processed.

Another great use for this would be /u/SethBling's "BASIC Programming Language in Minecraft" which could now very likely parse a script in a single tick; this tick might then take some seconds but it would be still much faster in total.

Closing words

This snapshot added really great new possibilities for map makers and I am really grateful to the developers for these changes!

One thing which would be great though is if the current measures to prevent loops were removed. I know loops can cause pretty bad damage because you are unable to save your game, but they add so many new possibilities as well. Therefor a gamerule like maxChainCommands could solve this in a more reliable way. The default value could be for example 2048. Every time the next chain command in a chain should run the game could test if alreadyExecutedCommandCount < maxChainCommands. This way infinite loops could be prevented and you could set a very low value during testing / building, but once you are done and there are large loops you can set it to a higher value (up to 2^31 – 1). If possible the maxChainCommands value should be retrieved every time in case a command in the chain changes it.

Edit: Apparently exactly that happened! Thank you so much Searge! The gamerule maxCommandChainLength with default value 65536 was added in 17w16b.