Here is a very simple bug in impulse command blocks. Go stand in a new superflat world and type this

/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"}
/setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b}
/blockdata ~1 ~ ~ {auto:1b}

Expected: "1 2" Actual: "2"

Compare:

/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"}
/setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b}
/setblock ~1 ~ ~-1 redstone_block

Expected: "1 2" Actual: "1 2"

The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.

You can witness this more directly by doing

/setblock ~1 ~ ~-1 air
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"}
/setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b}
/blockdata ~1 ~ ~ {conditionMet:1b}
/blockdata ~1 ~ ~ {auto:1b}

to show that conditionMet is the culprit.

There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,

/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"}
/setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b}
/blockdata ~1 ~ ~ {conditionMet:0b}
/blockdata ~1 ~ ~ {auto:1b}

would probably still print "2" instead of the expected "1 2".

The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.

Overall, my expectation is that

• UNconditional blocks ought not be affected by conditionMet, and
• in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former

Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.