EDIT: I have added a testing world for conveniently testing various instances of this bug. SMP commands not included.

First, I would like to mention one thing: the proper acknowledged behavior of a Comparator's output from a Command Block is the number of successes of the last executed command. This isn't only derived from observations - the actual NBT tag name describing the value comparators output is "SuccessCount".

This comes to the heart of the issue: the game has several commands which report "success" even when, ostensibly, they have failed. As a result, command block comparators will not output a reasonable expected value for these commands, and in fact, can output completely counter-intuitive values. This breaks various designs in command block circuits, as the comparator's output is simply incorrect for certain commands.

The technical cause of this bug appears to be the messages returned when using a command: if a command returns an error message (typically formatted in red text in chat, when used by a player or console, but obviously never witnessed by anybody when used by a command block), comparators will not consider it successful. Otherwise, it is counted as a success.

*TL;DR* The bug is that commands determine success/failure based on the messages they would send human users, and certain commands can fail while still being interpreted as successful, while others can succeed while being interpreted as failures, because of bugs in these messages. This breaks these commands' use in command block comparator output, and can also make the commands unintuitive for human users. The rest of this report is a list of commands which exhibit these bugs.

Affected commands

/effect

• Using lower amplifier
• Using same amplifier but lower time

In both cases the "show particles" argument may not change its value else it will update the effect

/help

The following is based on decompiled version of Minecraft 1.9 using MCP 9.24 beta. All method and class names are the names used in the decompiled version.

The problem is that the method net.minecraft.command.CommandHelp.execute(MinecraftServer, ICommandSender, String[]) throws a WrongUsageException, instead is should probably only print the correct usage.

public void execute(MinecraftServer server, ICommandSender sender, String[] args) throws CommandException
{
    if (sender instanceof CommandBlockBaseLogic)
    {
        sender.addChatMessage((new TextComponentString("Searge says: ")).appendText(seargeSays[this.rand.nextInt(seargeSays.length) % seargeSays.length]));
    }
    else
    {
        List<ICommand> list = this.func_184900_a(sender, server);
        int i = 7;
        int j = (list.size() - 1) / 7;
        int k = 0;

        try
        {
            k = args.length == 0 ? 0 : parseInt(args[0], 1, j + 1) - 1;
        }
        catch (NumberInvalidException numberinvalidexception)
        {
            Map<String, ICommand> map = this.func_184899_a(server);
            ICommand icommand = (ICommand)map.get(args[0]);

            if (icommand != null)
            {
                // Replaced this
                //throw new WrongUsageException(icommand.getCommandUsage(sender), new Object[0]);
                TextComponentTranslation textComponentTranslation = new TextComponentTranslation("commands.generic.usage", new Object[] {new TextComponentTranslation(icommand.getCommandUsage(sender))});
                sender.addChatMessage(textComponentTranslation);
                return;
            }

            if (MathHelper.parseIntWithDefault(args[0], -1) != -1)
            {
                throw numberinvalidexception;
            }

            throw new CommandNotFoundException();
        }

        //...
    }
}

/ban (and probably /ban-ip)

Let you ban players multiple times, however only one ban list entry is created

/pardon-ip

Always succeeds with a valid IP

/whitelist on and /whitelist off

Both always succeed, compared to /save-on and /save-off which fail when used if auto saving is already on respectively off this can be considered a bug

/scoreboard objectives setdisplay

• Clears an empty display slot
• Sets a objective that is already display in the specified slot to be display in that slot

/scoreboard players reset

Succeeds even if the entity has no score

/scoreboard teams join

Entity which is already in a team can join the same team again

/scoreboard players tag add

See MC-87430

Unaffected command

These commands are unaffected so you do not have to include them. I just want to point out why they are unaffected.

/gamerule

Only for MC-76044, however as it stores the incorrect value, the success is correct

The fact that it saves non existing gamerules is either intended or a different bug