'add field' UI should show why complex properties can't be added

An explanation would be ideal, not so much cause I care to index some of the field properties but that I get opaque warnings in the reports tab Warning while retrieving available fields for index index: could not find a type mapping for the following fields Solution type » Taxonomy term (type entity:taxonomy_term) even though without the add button I wouldn't even try to index it since that is completely disabled. Also it looks like the types are allowed are just hardcoded in the module is that correct?

/**
   * Retrieves the mapping for known data types to Search API's internal types.
   *
   * @return string[]
   *   An array mapping all known (and supported) Drupal data types to their
   *   corresponding Search API data types. Empty values mean that fields of
   *   that type should be ignored by the Search API.
   *
   * @see hook_search_api_field_type_mapping_alter()
   */
  public static function getFieldTypeMapping() {
    // Check the static cache first.
    if (empty(static::$fieldTypeMapping)) {
      // It's easier to write and understand this array in the form of
      // $search_api_field_type => array($data_types) and flip it below.
      $default_mapping = array(
        'text' => array(
          'field_item:string_long.string',
          'field_item:text_long.string',
          'field_item:text_with_summary.string',
          'text',
        ),
        'string' => array(
          'string',
          'email',
          'uri',
          'filter_format',
          'duration_iso8601',
          'field_item:path',
        ),
        'integer' => array(
          'integer',
          'timespan',
        ),
        'decimal' => array(
          'decimal',
          'float',
        ),
        'date' => array(
          'date',
          'datetime_iso8601',
          'timestamp',
        ),
        'boolean' => array(
          'boolean',
        ),
        // Types we know about but want/have to ignore.
        NULL => array(
          'language',
        ),
      );

      foreach ($default_mapping as $search_api_type => $data_types) {
        foreach ($data_types as $data_type) {
          $mapping[$data_type] = $search_api_type;
        }
      }

      // Allow other modules to intercept and define what default type they want
      // to use for their data type.
      \Drupal::moduleHandler()->alter('search_api_field_type_mapping', $mapping);

      static::$fieldTypeMapping = $mapping;
    }

    return static::$fieldTypeMapping;
  }

and there is a hook to alter the mappings but what happens if I were to alter the taxonmy term type mapping wouldn't this just blow up, I think knowing why I cant would help out there.

You should be able to just add a mapping from entity:taxonomy_term to integer. We could also just do it in the module, I guess. The log message is there so we can collect data types which we missed before and add them to the mapping. But I guess we'll have to (or, at least, should) remove it before creating a stable release. In production use, the warning is really too confusing – as you say, it doesn't really warn you that anything is wrong on your site, it just warns the module's developers that there are data types they didn't include in the mapping.
At that point, we could also think about whether we want to do anything else with that information, to better inform users.

Two patches: the first would just remove the warning, the second would move it to the bottom of the page and give instructions what to do about it.
Any opinions on which we should commit, or suggestions for a third alternative? (Also, suggestions for improving the phrasing of all text in the new UI element are very welcome.)

I like the second option, it still gives you the notification but doesn't push it to reports (where truthfully I never check, someone else brought it to my attention and I was trying to figure out how I screwed it up). I know it probably not possible to say why the storage is unavailable but that would nice (wishful thinking). My only real comment on verbage is maybe change:
The following fields cannot be indexed since there is no type mapping for them:
to
The following fields cannot be indexed as they have no available(usable) type mappings:

But that is just my brain spitting that out as what I understand the problem to be; the storage definition for a particular field is unavailable because of xy reason. Probably some custom storage being used my those fields.

+1 for RTBC but will wait to see if anyone else has any other comments.

Thanks for reviewing, both of you!
Committed.

But that is just my brain spitting that out as what I understand the problem to be; the storage definition for a particular field is unavailable because of xy reason. Probably some custom storage being used my those fields.

No, not quite. It's that, for some reason, we don't have a mapping for the property's type to one of our Search API data types. Either because we don't know about the type, or because the type (as in the case of entity:*) represents complex data which can't just be indexed in a single field.