States API creates jank (layout shift) on page load

Regarding this issue her is a list of states which can really damage layout shifting:

• visible
• invisible
• expanded
• collapsed

First two states can be used for any thing, while the last two states are for the details html element (playing around open html attribute).

Now about visible/invisible states. We can have something like

   $form['something'] = [
      '#type' => 'fieldset',
      '#title' => $this->t('Some title'),
      '#states' => [
        'visible' => $something,
      ],
    ];

With the code above we adding state `visible` directly to the container of some elements.
While with this code:

  $form['something'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('Something'),
      '#states' => [
        'visible' => $something,
      ],
    ];

we adding state directly to checkbox. But rendering system in Drupal provides form_element hook theme which is actually a wrapper of form elements. And according to states.js

  $document.on('state:visible', (e) => {
    if (e.trigger) {
      let $element = $(e.target).closest(
        '.js-form-item, .js-form-submit, .js-form-wrapper',
      );
      // For links, update the state of itself instead of the wrapper.
      if (e.target.tagName === 'A') {
        $element = $(e.target);
      }
      $element.toggle(e.value);
    }
  });

we are not actually hiding/showing checkbox itself. We hiding/showing container (form-element container) element.

=====

What i want to say is that we can't solve this issue just by using CSS media query "scripting". Instead, here should be more complex logic which can give frontender some attributes or classnames of initial state.

Here is example:
1. Visit /admin/config/development/settings page
2. Initially all checkboxes are unchecked.
3. If you will toggle "Twig development mode" checkbox and then click on save btn
4. On the next visits of this page initial state will be different. Because checkbox is initially checked, so container element which is sensitive to the state of this checkbox should be initially visible. <-- here we are missing some helpful attributes or classnames, just to detect initial state to understand which CSS rules we should write.

If initial state should be "visible" -> we don't need to hide anything.
If initial state should be "hidden" -> we should hide element using CSS.

====
Summarizing:
We have to have some extra html attribute or classname above the element with state which explains initial behavior.

Added proof of concept in merge request. You can test on '/admin/config/development/settings' page

The issue summary mentions using at-media scripting feature, but proof of concept seemed to go a different route. Could it be explained some/documented in issue summary why a different approach is needed?