[explicit-module-boundary-types] allowTypedFunctionExpressions no longer applies to arguments

[G-Rath]

Repro

Here's the repo itself: https://github.com/G-Rath/terraport/blob/master/src/formatter/ensurers.ts#L10

{
  "rules": {
    '@typescript-eslint/explicit-module-boundary-types': [
      'error',
      {
        allowTypedFunctionExpressions: true
      }
    ],
  }
}

export type Ensurer = (blocks: TFBlock[]) => TFBlock[];

export const myEnsurer: Ensurer = blocks => {
  return blocks;
};

Expected Result
blocks should not require a type, due to the type annotation on the variable.

Actual Result

ESLint: Argument 'blocks' should be typed.(@typescript-eslint/explicit-module-boundary-types)

Additional Info

Overall, explicit-module-boundary-types seems to have jumped in noise, as it's now erroring on a lot of my code.

For example:

export const ensureLabelsHaveLeadingSpace: Ensurer = blocks =>
  walkNodes(blocks, {
    Label: node => {
      node.surroundingText.leadingOuterText = ensureTextStartsWithTokens(
        node.surroundingText.leadingOuterText,
        [{ type: TokenType.Whitespace, content: ' ' }]
      );
    }
  });

I've now got block & node being marked as errors due to not being annotated with a type.
I've focused on block for now in this issue, but it seems like the behaviour is to now require a type definition for any function that is within a function that is exported.

Another example:

export const walkNodes = <TTheNode extends TFNode>(
  nodes: TTheNode[],
  listeners: NodeListeners
): TTheNode[] => nodes.map(node => walkNode(node, listeners));

Here node is marked as requiring a type, which I'd argue it shouldn't as it's not at the boundary - it's internal as an implementation detail.

It seems to me like #1490 might have had the opposite effect?

(It could be that I've misunderstood the intention of the rule, in which case I can turn this into a feature request I guess?)

Versions

package	version
@typescript-eslint/eslint-plugin	2.18.1-alpha.5
@typescript-eslint/parser	2.18.1-alpha.5
TypeScript	3.7.5
ESLint	6.8.0
node	12.14.1
npm	6.13..6

[bradzacher]

Nah, this was my fault in #1493.
I refactored the code to reduce duplication and in doing so broke the fact that allowTypedFunctionExpressions works slightly differently in this rule.
Fixing it now.