This is a slight refactor where selectorName and selectorArgs are directly referenced as selector arguments instead of accessing them as args[ 0 ] or args[ 1 ].

Here we no longer need to exclude the metadata selectors because mapResolveSelector is no longer ever called with a metadata selector. We are more careful now about which kind of selector is mapped/bound with which mapping function.

It was very helpful to refactor functions that map all selectors at once:

function mapSelectors( selectors ) {
  return mapValues( selectors, ( selector ) => { /* do the mapping */ } );
}

to a function that maps just one selector at a time, allowing us to do the mapping more granularly and precisely:

function mapSelector( selector ) {
  /* do the mapping */
}
const mappedSelectors = mapValues( selectors, mapSelector );

Is the extra call just a side-effect of refactoring that can't be avoided, or an actual bugfix?

The multiple calls to normalize are a side-effect of how we're building functions that are both a public API exposed to users, and also a primitive used to build more complex functions. Examples:

1. A selector function passed by store author in options is "bound" to the store: a foo( state, ...args ) function is wrapped in a function that binds the state argument and normalizes the args. This wrapped function is what is called by consumers in select( store ).foo().
2. If there is a resolver specified, the already "bound" selector from the previous step is further wrapped in another function that calls the resolver as a side effect. The args for the resolver also need to be normalized. Then the "bound" selector is called with args that are already normalized. The normalize call happens twice.
3. The metadata selectors like hasFinishedResolution( selName, selArgs ) are also exposed as public API, and therefore the "bound" version needs to normalize selArgs. But at the same time hasFinishedResolution is used internally to build the resolveSelect primitive, hasStartedResolution is called to check if we really need to call resolver when calling selector. That's a third normalize call.

I think it's possible to avoid the extra normalize calls with a careful refactoring, but I think it's a topic for a separate PR.

Makes sense. Thanks for the detailed explanation!