The bug

In 1.12, when a command block runs a command, its SuccessCount will (typically) be dependent on the number of targets affected, otherwise a simple 1 for success and 0 for failure.

Now in 1.13, SuccessCount will be the "result" return value rather than a simple 1 or 0 of "success". I'm assuming that a separate return value based on the number of affected targets is not feasible, but result behaves much differently than the old SuccessCount equivalent.

This has some obscure consequences depending on the command being run, particularly when it comes to the "conditional" setting of a command block, which relies on the previous command's SuccessCount being 1+. Such conditional command blocks will fail to run if the command block behind them succeeded, but had a "result" return value of 0.

Reproduction

/scoreboard players set will provide a "result" value of playerCount * score. If score was 0, the return value for "result" will be 0. At the same time, the return value of "success" will be 1 since the command did succeed. But a conditional command block will fail due to the use of "result".

Some example commands to put into an unconditional command block that prevents a conditional command block from running, despite being successful:

At all times (standard score reset):

/scoreboard players set @a[scores={OBJ=1..}] OBJ 0

At all times:

/weather clear 0

Only if it's day 0:

/time query day

Only if it's Peaceful difficulty:

/difficulty

Only if the player is in the Overworld:

/execute as @p[distance=..3] store result score @s OBJ run data get entity @s Dimension