onBlur behaviour is affected by "touch capabilities"

Are you reporting a bug or runtime error?

That's not really a bug, and not an error - this is a not correct behavior.

There is an option - blurInputOnSelect

• blurInputOnSelect: isTouchCapable(),

and the effect of it quite simple:

  selectOption = (newValue: OptionType) => {
    ....
    if (blurInputOnSelect) {
      this.blurInput();
    }

Problems

1. Should it be delayed?
   In normal conditions there are two different events (click/change, blur) comes one after another with a little "gap" between them. But in this case - there is no gap. This results into some differences in the "state management" - blur evens is reported too soon - before the change(or select) event is finishing propagation (state change applied back to the component).
   Probably onBlur should be called in setTimeout, or at least a Promise

2. Should it even exists?
   For all "touch devices", windows 10 on hybrid devices included, or only when select is caused by "touch" event? Probably here we should check touch event, and execute blur only there, but not as a part of selectOption

3. Is it a real problem? Yes, it is. We run into it twice this year, causing SEV1s both times.

Start in packages/react-select/src/Select.js at the blurInputOnSelect option, selectOption, and the touch-event handling referenced in the issue. Reproduce the ordering between selection and onBlur, then determine the intended behavior for touch-capable and hybrid devices. Done requires a maintainer decision on both timing and when blur should occur, followed by coverage for that behavior.