Post ES2015 breaking change to If statement completion value?

[allenwb]

This was first discussed in a do expression proposal issue tc39/proposal-do-expressions#21 (comment)

The behavior of if seems to have changed between ES2015 and the current ES2018 draft:

In 2015:

{ 1;
if (true) break;
}

produces the completion value for the block: [[Type]: break, [[Value]]: 1

and

{ 1;
if (true) ;
}

produces the completion value for the block: [[Type]: Normal, [[Value]]: undefined.

In the ES2018 draft, they respectively produce:
[[Type]: break, [[Value]]: undefined
[[Type]: Normal, [[Value]]: undefined

The algorithm conventions for manipulating completion results changed between those versions of the spec. It isn't obvious to me that the semantic change was intentional. It could be a bug introduced when rewriting using the new conventions. It probably should be researched to see if the 2015 behavior had been identified as a bug and the change was an intentional fix.

The bigger question is what (if anything) was the intent of "completion reform" for cases like this. It's pretty clear that a goal of completion reform was that during linear progress, each statement either always or never produces a new completion value. But abrupt completions are really a separate dimensions of completion value propagation, so it isn't obvious that the always/never rule should apply to it.

In seems strange to me that:

{ 1;
break;
}

would have a completion value of [[Type]: break, [[Value]]: 1
But,

{ 1;
if (true) break;
}

has a completion value of [[Type]: break, [[Value]]: undefined

If in fact this change was unintentional and broken when the algorithm conventions changed, then other places that might have been similarly broken should be inspected.

[anba]

This was changed in #101.

[anba]

This was changed in #101.