New devices come out as light.kitchen_kitchen_light_1 — where is the second room name coming from?

On the three options, having gone round this with a config about the same age as yours:

Dropping the room from device names going forward is the one I would pick, and the reason is not that the new pattern is better. It is that you now have two systems competing to tell you the same fact, and only one of them is maintained. The area is a field you can change in one click; the room baked into a device name is a string you have to remember to update. Keeping both means keeping them in sync by hand, forever.

The fear people have is that friendly names get useless — that you end up staring at a list of eleven things called "Light 1". In practice that is less bad than it sounds now, because areas are shown next to entities in the pickers and on cards in a way they simply were not when we all started doing this. The information did not disappear, it moved to somewhere that updates itself.

The honest counter-argument is the one about devices that move. If a bulb goes from the kitchen to the hall, its area updates and its entity ID does not, so you end up with light.kitchen_* in the hall. That is worse than the old scheme, where at least the wrong room was in a field you could edit. If you move things around a lot, neither option is clean and you are choosing which flavour of wrong you prefer.

What I would not do is retro-fix. Pick the rule, apply it to everything from here on, and leave the existing entities exactly as they are. A config with a visible date-line in it is annoying. A config where half the references are broken is a weekend.

You have not missed a setting, and the reason nothing has broken is worth understanding properly, because it is also the reason that button is dangerous.

What changed. The pattern for newly generated entity IDs picked up the area as a prefix in the 2026.6 release; 2026.5.4 is the last version that generated them without it. So the shape went from device_property to area_device_property.

Why yours is doubled. Because the area is in your device name as well. Nothing checks for that — the area segment is prepended whether or not the device name already contains the same word. Everybody who adopted your convention got the same result, and for the same reason: the convention exists precisely because the ID used to lack the area.

Why nothing broke. This is the important half. An entity ID is reserved, not derived. An entity that reports a unique ID claims its entity ID the first time it is registered and keeps that string forever afterwards. It is stored in the registry, not recomputed from the device name and area each time it loads. Upgrading therefore renames nothing, which is why your old dashboards are fine and always were going to be.

So the new pattern only ever touches entities that are created after you upgraded. In practice that means:

• a new device or a new integration
• an entity you enable that had been disabled on a device you already had
• removing and re-adding something
• helpers you create from the UI
• and anything you deliberately regenerate

Which brings you to the button. No, it is not safe as a tidying tool, and it is the one operation that converts your cosmetic inconsistency into a real outage. "Recreate entity IDs" throws away the reservation and generates a fresh ID under whatever the current pattern is. That is not a repair — it is exactly the rename you have so far avoided, applied on purpose.

One more thing that surprises people: the area in the ID is a snapshot of the moment the entity was created. Move the device to another room afterwards and the ID keeps the old area in it. It does not follow the device, and nothing warns you that it has gone stale.

Adding the specific trap, because there is now a bulk version of that button and it is much easier to reach than it used to be — you can select every entity at once from the entities list and regenerate the lot from the menu.

What it does not do is update a single thing that refers to them.

• Automations and scripts keep the old string. They do not error. They just stop firing, which you discover days later when a light does not come on.
• Template sensors referencing the old ID return unavailable or unknown, and templates are forgiving enough that a broken one often renders as an empty string rather than a failure.
• Dashboard cards show an entity-not-found tile, which is at least visible.
• Long-term statistics and history are keyed on the entity ID. A rename does not carry the history across; you get a fresh series under the new name and the old one sits there orphaned. Utility meters and anything doing month-on-month comparison are the ones that hurt.
• The recorder database keeps the old rows under the old ID either way.

If you decide to do it anyway, do one device first, then search your whole config directory for the old string before you touch the second one. Not because you will forget an automation, but because you will forget the template sensor inside the automation.

There is community tooling that scans dashboards for entities that no longer exist, which is worth having pointed at your setup before and after any rename — it will not find template references, but it clears the noisiest category fast.