How to fix the core.extension.module list when the currently active profile has been added to it by the system?

Question

Following the 8.6 upgrade, several of our sites have developed a strange problem. The currently active profile, let's call it foo_profile, is now also listed as a module in config (core.extension.module).

This leads to the backend of the site becoming unavailable at seemingly random intervals, until a cache is cleared. The error that's being logged is:

The module foo_profile does not exist.

Which makes sense, since it's not a module.

I know there were some updates to profiles in 8.6, but I couldn't find anything that would help to explain. settings.php for all sites contained this prior to the upgrade:

$settings['install_profile'] = 'foo_profile';

After getting the exception, I removed that line from one of the sites, just in case. It made no difference, so my conclusion is that having that line or not doesn't affect this problem.

I tried simply removing the non-module from the list:

$conf = \Drupal::configFactory()->getEditable('core.extension');
$modules = $conf->get('module');
if (isset($modules['foo_profile'])) {
  unset($modules['foo_profile']);
  $conf->set('module', $modules);
  $conf->save();
}

That didn't overtly break anything, but now I have warnings when visiting the status report and similar pages:

Notice: Undefined index: name in system_requirements() (line 52 of core/modules/system/system.install). system_requirements('runtime') call_user_func_array('system_requirements', Array) (Line: 403) Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) (Line: 112) Drupal\system\SystemManager->listRequirements() (Line: 49) Drupal\system\Controller\SystemInfoController->status() call_user_func_array(Array, Array) (Line: 123) Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() (Line: 582) Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124) Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97) Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() (Line: 151) Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68) Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57) Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47) Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99) Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78) Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47) Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52) Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23) Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 665) Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Since the problem recurs on its own schedule, I'm not convinced that's done anything to resolve the underlying issue.

So...how do I fix this?

As a bonus, how on earth did this even happen in the first place?