Currently, when adding an area plugin to a view's display (like say for example a "text_custom" type area), Views automatically generates a machine name, based on the type of area, suffixed by an incremented number, corresponding to the number of areas of the same type already in place.
This works fine, until you decide to customize the output of this display, through a custom template.
Then, when deciding how to print the variable containing those areas, (for example {{ footer }}), you might decide to split those areas (for example, using {{ footer.area_text_custom }} somewhere inside your markup, then {{ footer.area_text_custom_1 }} elsewhere).
If later on you need to delete any or all of those areas, and don't re-create them all, using the exact same order, you will break this template customization.
The solution would be to leave it up to the site builder, through the UI, to set a pre-determined area handler id.
Active
11.0 🔥
views.module
I added a rough proof of concept which works ok.
I had to add the Method Drupal\views\Plugin\views\area\AreaPluginBase::submitOptionsForm() has no return type specified. phpstan error to the list of ignored errors in core/.phpstan-baseline.php since \Drupal\views\Plugin\views\area\Entity already implements it and would break.