@tofumatt It's not filled I think, I just noticed it when fixing other IE11 bugs :)

Agree that this was pretty critical to fix, but this needs to be refactored in a subsequent pull request since we're already assuming the fallback values in the assignment of the const. It should either be corrected there, or removed from there (ideally the former).

I can plan to set aside some time to take a look.

@youknowriad thanks for fixing, and let's refactor :)

I do suspect the main issue here is that our Babel runtime transform is converting the Symbol check in HAS_SYMBOL assignment to the version used by core-js, so effectively HAS_SYMBOL will always be true, and Symbol.for will use the polyfilled version. This is unlike in React, where Symbol is not polyfilled and thus will use the fallback value. The mismatch in behavior is likely what caused the switch not to properly catch the type of the element.

I've having trouble finding a way to detect true native environment support for Symbol without triggering the replacement by the runtime transform.

Another option would be to avoid (re-)defining the React constants, and instead generate a dummy pair of Provider / Consumer components and access the $$typeof property of them to use in the switch. I avoided this purely for the memory overhead of creating an unused component, but it seems more stable given the issues faced with trying to define the Symbol value.

For historical context, this was a regression of #8189