Copy block configuration from admin theme when enabling an admin theme

This is popping up in the Recipes initiative. We can enable and configure a theme, but because of the block duplication of the existing theme, a recipe creator needs to know which theme the recipe is installed over to be able to place/modify the blocks.

Since themes can (and do) provide blocks from their own config now, do we need the duplication functionality at all?

I agree with @thejimbirch in #15. Can we not just rip out the bizarre duplication stuff? Why do we still need it? AFAICT, it just interferes with the ability of themes to provide blocks that make sense for them.

Yes. I have also run into this problem, specifically while enabling themes with recipes. It does seem like pretty bizarre behavior to me, but I've never lived in a world without it... so :shrug:

It looks like this is happening in block.module, in the block_theme_initialize() function (which is called from the block_themes_installed() hook). WE c

/**
 * Initializes blocks for installed themes.
 *
 * @param $theme_list
 *   An array of theme names.
 *
 * @see block_modules_installed()
 */
function block_themes_installed($theme_list) {
  // Disable this functionality prior to install profile installation because
  // block configuration is often optional or provided by the install profile
  // itself. block_theme_initialize() will be called when the install profile is
  // installed.
  if (InstallerKernel::installationAttempted() && \Drupal::config('core.extension')->get('module.' . \Drupal::installProfile()) === NULL) {
    return;
  }

  foreach ($theme_list as $theme) {
    // Don't initialize themes that are not displayed in the UI.
    if (\Drupal::service('theme_handler')->hasUi($theme)) {
      block_theme_initialize($theme);
    }
  }
}

It looks like we're already aware of some issues during profile installation and skip this block duplication then. If the duplication cannot be removed, perhaps we could also make a special case and not do it if a recipe is being applied.

(Personally, I don't like the special treatment approach for recipes. Since a recipe can be applied to a site at any time, I don't think it makes much sense to treat them the same as an installation profile, rather it should be treated the same as though someone manually enabled the theme, at least by the theme system.)

Can we update this issue to be all themes and not just admin themes?

I see we have two paths forward we could take.

1. Remove the block duplication code completely and require themes to provide their own block configuration. AFAICT, they should/do already.

2. Add an exemption for recipes in block_theme_initialize() like there is for install profiles.

Is there any progress on this, or any way to circumvent this and move forward?
Recipes are included in 10.3.x, I feel like the priority of solving this should be a little higher now.

I can't seem to get it fixed myself, other than patching core and removing the functionality entirely, but that seems a little nuclear...

On the other hand, I personally do think that this copy functionality should be removed.
It definitely doesn't make much sense to copy blocks from one theme to another, given that regions could be entirely different.