Lost user input when attempting to configure disabled fields on entity displays

I'm going to triage this.

I was able to reproduce this in 8.4.x locally. Following steps in the summary:
Steps to reproduce
On /admin/structure/types/manage/article/display, move the Tags field to disabled and save the form.
Change the "Label" or "Format" options for the Tags field and save again. The change is not actually saved.

I also updated the description--changed "manage form display" to "manage display" to more accurately reflect what's reported in the gif and the steps to reproduce.

However, a similar issue exists in Manage form display when the field is moved to Disabled and the widget type is not saved.
Steps to reproduce
On /admin/structure/types/manage/article/form-display, move the Tags field to disabled and save the form.
Change the "Widget" options for the Tags field and save again. The change is not actually saved.

So one option is to use the 'visually-hidden' class which really is the easiest one, but maybe not the prettiest :)

I've played with #access, but that's not an option since the javascript needs the format select element to be there. Unless we start changing that of course.

Needs tests. If we can agree on using the css trick, I can quickly write a test for it.

The patch dint worked for me. I checked the issue and found the below code where they are removing the compound if the field is in hidden state and not saving any value.
as @xjm suggested why we need to change the value of the field display setting which is in hidden stage? since it is not viewable to user.
So i am changing the priority to 'Normal'

      if ($values['region'] == 'hidden') {
        $entity->removeComponent($field_name);
      }
      else {
        $options = $entity->getComponent($field_name);

        // Update field settings only if the submit handler told us to.
        if ($form_state->get('plugin_settings_update') === $field_name) {
          // Only store settings actually used by the selected plugin.
          $default_settings = $this->pluginManager->getDefaultSettings($options['type']);
          $options['settings'] = isset($values['settings_edit_form']['settings']) ? array_intersect_key($values['settings_edit_form']['settings'], $default_settings) : [];
          $options['third_party_settings'] = isset($values['settings_edit_form']['third_party_settings']) ? $values['settings_edit_form']['third_party_settings'] : [];
          $form_state->set('plugin_settings_update', NULL);
        }

        $options['type'] = $values['type'];
        $options['weight'] = $values['weight'];
        $options['region'] = $values['region'];
        // Only formatters have configurable label visibility.
        if (isset($values['label'])) {
          $options['label'] = $values['label'];
        }
        $entity->setComponent($field_name, $options);
      }

What if we make the form fields disabled instead of hiding them altogether?

I found that when I hid them, the column widths adjusted to space out evenly, and, in some cases, it was annoying because it was a pretty significant jump. It's really noticeable on the default Basic page when you move the Body field to disabled, but leave Links displayed.

If disabling them isn't the right approach, I'll work on hiding them, but I wanted to check on it.

Here's POC for the disabled fields:

A different solution would be to actually store the configured settings for disabled fields, but that would require a data model change as well.

It's pretty annoying as a site builder if you want to disable a few fields to test out some layout variation, then you re-enable them only to find you also have to reconfigure them. If you have a lot of formatter 3rd-party add-ons that's very tedious, and you will forget something.

I also have a more advanced use case - allow layout builder content field blocks to use the configured settings as defaults, and optionally hide that whole formatter mess from site editors who are using layout builder. I've just been working on a proof of concept that stalled on this issue.