Minor: If we rely on the behavior to fall back to object, wonder if we should put this in a common getter function between the constructor and runSelection usage, e.g.

static function getNextMergeProps( props ) {
	return mapStateToProps( select, props ) || {};
}

Shouldn't it be?

const defaultMergeProps = {};
static function getNextMergeProps( props ) {
	return mapStateToProps( select, props ) || dedefaultMergeProps;
}

Unless it doesn't matter, I'm not sure :)

Unless it doesn't matter, I'm not sure :)

It shouldn't matter. We're running a shallow equality on the result, so, with your example:

isShallowEqual( test(), test() );
// true

That said, it could be a micro-optimization since strict equality is a shortcutting case in @wordpress/is-shallow-equal:

https://github.com/WordPress/packages/blob/c24da3afe3fa4b1ccd234f8c2ec766d43201c1ce/packages/is-shallow-equal/objects.js#L16-L18

This would only happen on cases where we're returning undefined (falsey), which for withSelect is probably not so frequent.

Can you clarify what the potential issue is that warranted the assignment here? Can we add a unit test which would otherwise fail without it?

you can't setState if the component is not mounted so selection can be only run when the component is really mounted.

How do we get from setState to having runSelection being called?

runSelection calls setState?

You mentioned that the issue is setState could be called between constructor and componentDidMount. When will that occur?

Oh, I don't know exactly :) I just had errors when loading Gutenberg when I tried.
Also, I guess in an async React mode, Components can be initialized but not mounted directly which means a lot of subscribe calls will happen in between.

We should track it down and get a unit test in place which would fail without this assignment.

Haha, it looks like I'm not able to reproduce anymore :). Maybe it was related to another fix I did. I'm removing this for now