Document Interface language vs. content language block

Indeed I can confirm this!

Trying to fix this in code I found the important part: The maintainer already solved this VERY smart:

  /**
   * {@inheritdoc}
   */
  public function getDerivativeDefinitions($base_plugin_definition) {
    $language_manager = \Drupal::languageManager();

    if ($language_manager instanceof ConfigurableLanguageManagerInterface) {
      $info = $language_manager->getDefinedLanguageTypesInfo();
      $configurable_types = $language_manager->getLanguageTypes();
      foreach ($configurable_types as $type) {
        $this->derivatives[$type] = $base_plugin_definition;
        $this->derivatives[$type]['admin_label'] = $this->t('Dropdown Language (@type)', ['@type' => $info[$type]['name']]);
      }
      // If there is just one configurable type then change the title of the
      // block.
      if (count($configurable_types) == 1) {
        $this->derivatives[reset($configurable_types)]['admin_label'] = $this->t('Dropdown Language');
      }
    }

    return parent::getDerivativeDefinitions($base_plugin_definition);
  }

So you simply have to use the other dropdown language block "Dropdown language (Content)". There's one for each language type! :)

Derivatives in the Block API are a interesting little treat.

This seems like the very discovery that is the cause of v1-v2 progression for this module.

noting (contrib releasing): a flaw in the Block API happens to be if you have already initialized a block definition, you can not add a deriver after..

linking

#7

Because different blocks for different language types are only available AFTER checking "Customize Content language detection to differ from Interface text language detection settings".