One form-control name per independent drop, renumbered the way MishkaCmsBuilder.Ids renumbers an id.

Why a second copy is a second control

A palette entry arrives furnished, and a furnishing names its controls: chelekom-headless-segmented-control arrives as name="period", Day, Week and Month. Its segments are radio buttons, and the browser groups radio buttons by name within one form, or within the page outside any form. Two dropped controls were therefore ONE group: choosing Month in the second cleared Week in the first, and only one of them ever showed a selection.

Which names this touches

Only a name a component renders on a form control — name={@name} on the <input>, <select> or <textarea> its own markup draws — and only a literal one. A component the kit calls a FIELD is left to MishkaCmsCore.Runtime.Authoring.PageForms.FormPlacement, which binds its name to the form it joins (name={f[:period].name}); a bound name is an expression and is never a candidate here either. chelekom-icon's name is an icon and is left alone, because the icon's markup draws no control with it.

The arrival yields, inside one form

The same rule Ids.dedupe/2 follows: arrived is what the op just created, and only those are renamed — the control already on the page keeps the name a handler may already read. A name is taken within its scope, the form around it or the page outside every form, which is where HTML groups radio buttons and where a submission collects its keys; the same name in two forms is two names. Arrivals that share a name share it on purpose — a worked example with a group in it — so they are renamed together, to one new name.

Numbering fills gaps: period beside period_3 gives period_2. The suffix follows a form key's spelling (PageForms.Naming's email_2), and goes inside a trailing [] or ] so tags[] becomes tags_2[].