content_moderation_entity_bundle_field_info overrides the target bundle setting on the field definition for all bundles

Yes, they get serialized and the bug can be reproduced only if you retrieve the bundle fields for two different bundles in the same request.

I would expect the following to fail the assertion:

$entity_field_manager->clearCachedDefinitions();
$fields_a = $entity_field_manager->getFieldDefinitions($entity_type_id, $bundle_a);
$fields_b = $entity_field_manager->getFieldDefinitions($entity_type_id, $bundle_b);
$this->assertNotEqual($fields_a['moderation_state']->getTargetBundle(), $fields_b['moderation_state']->getTargetBundle());

P.S.:
I've just seen that the target bundle is being set automatically for the fields returned by the hook implementations entity_bundle_field_info. Therefore it should be enough just to return the field from the hook. From \Drupal\Core\Entity\EntityFieldManager::buildBundleFieldDefinitions():

    // Automatically set the field name, target entity type and bundle
    // for non-configurable fields.
    foreach ($bundle_field_definitions as $field_name => $field_definition) {
      if ($field_definition instanceof BaseFieldDefinition) {
        $field_definition->setName($field_name);
        $field_definition->setTargetEntityTypeId($entity_type_id);
      }
      if ($field_definition instanceof BaseFieldDefinition || $field_definition instanceof FieldDefinition) {
        $field_definition->setTargetBundle($bundle);
      }
    }

The sample test code you've given would pass, because like you said getFieldDefinitions sets the target bundle.

No, it will not because the second one will set the bundle on the same object.

I still think that the steps to reproduce in #4 should be sufficient to reproduce the bug.

+++ b/core/modules/content_moderation/content_moderation.module
@@ -79,9 +81,29 @@ function content_moderation_entity_bundle_field_info(EntityTypeInterface $entity
+    $definition = FieldDefinition::createFromFieldStorageDefinition($base_field_definitions['moderation_state'])
+      ->setTargetBundle($bundle)
+      ->setLabel(t('Moderation state'))
+      ->setDescription(t('The moderation state of this piece of content.'))
+      ->setComputed(TRUE)
+      ->setClass(ModerationStateFieldItemList::class)
+      ->setDisplayOptions('view', [
+        'label' => 'hidden',
+        'region' => 'hidden',
+        'weight' => -5,
+      ])
+      ->setDisplayOptions('form', [
+        'type' => 'moderation_state_default',
+        'weight' => 100,
+        'settings' => [],
+      ])
+      ->addConstraint('ModerationState', [])
+      ->setDisplayConfigurable('form', TRUE)
+      ->setDisplayConfigurable('view', FALSE)
+      ->setReadOnly(FALSE)
+      ->setTranslatable(TRUE);

It would be great if we add a method on FieldDefinition for copying all that stuff from the base field definition, because it looks like this might be used a lot.

   public function getConfig($bundle) {
+    if ($this->getFieldStorageDefinition() instanceof FieldDefinitionInterface) {
+      return $this->getFieldStorageDefinition()->getConfig($bundle);
+    }

That will return the BaseField override as it will invoke \Drupal\Core\Field\BaseFieldDefinition::getConfig(), right?

In the hook we create the FieldDefinition out of the BaseFieldDefinition:
+ $definition = FieldDefinition::createFromFieldStorageDefinition($base_field_definitions['moderation_state']).

Therefore I think that it might make sense to return the base field override in FieldDefinition::getConfig() if the field storage definition is a base field. I am only not sure if we should it general as you are proposing or limit it to instances of BaseFieldDefinition.

Yeah, that may need a dedicated issue, I'm not sure.

A dedicated issue would be better.