Part of #39281

Besides just marking that a block is a setting, the block should also contain some meta-information about what type of section it is, e.g., a 404, a call to action, etc. (I think this meta information can be stored as an attribute)

We have three options:

A new section block that patterns can use.
A group block variation, e.g., some attribute that marks that the group is a section and add/or add attributes with the meta-information.
A block supports flag. Any block can use a flag to specify using the supports mechanism it is a section. Using hooks as we do for colors etc, when we detect that the block supports being a section, we automatically add some attributes to the block, the UI reacts differently to show section information like name etc. Using this approach, groups, cover, columns, template parts can all be sections.
As part of the task, we should analyze the tradeoffs, choose one of the options and document why it was chosen, and then implement one of the options.

Without a deep analysis, I think the block support approach seems to be the right one (it allows any block to be section, even third-party ones), it does not involve any specific wrapper, and I don’t see any advantage to the other approaches provide.

The initial UI work of this task is small. I’m only expecting that if the section has a name/semantic meaning, the UI shows it on the block toolbar. Like on this mockup: