Deprecate remove + add of entities when entity ID changes

[emontnemery]

Background

When an entity's entity IDis reloaded, the entity's async_will_remove_from_hass followed by async_added_to_hass methods are called. The intention is that this will make entities resubscribe to listeners, which could potentially be influenced by entity_id.
However, this design causes problems:

• It's very rare that integrations set up listeners or do other things which is influenced by the entity in async_added_to_hass
• Many integrations end up with their entities in a broken state after async_will_remove_from_hass + async_added_to_hass have been called; some integrations (incorrectly) set some things up in __init__ and tear them down in async_will_remove_from_hass
• The entity is not informed in the call to async_will_remove_from_hass that the entity will be reused. This for example means scripts and automations are stopped on entity ID change, which in real is not necessary just because the entity ID changed

Proposal

Deprecate readding of entity objects when entity ID changes, and replace with a new method async_entity_id_changed which integrations can override.

Core integrations

No deprecation period, we'll immediately stop calling async_will_remove_from_hass followed by async_added_to_hass on entity ID change.
Integrations which reference entity_id in async_will_remove_from_hass or async_added_to_hass will be updated.

Custom integraitons

During the deprecation period, the default implementation of async_entity_id_changed will be the same as async_will_remove_from_hass followed by async_added_to_hass , after the deprecation period it will be empty.

Result of audit of core integrations and custom integrations in HACS

Core integrations

701 files implement at least one of async_will_remove_from_hass or async_added_to_hass.
50 of those have issues in or assymetry between async_will_remove_from_hass and async_added_to_hass

There are 67 classes which reference entity_id in async_added_to_hass for purposes other than logging, 13 of those do not correctly handle the entity id change.

Custom integrations

Of a total of 2263 custom integrations:

• 950 integrations implement async_added_to_hass or async_will_remove_from_hass (either or both)
  • 371 (39%) of those seem to have an assymetry between async_added_to_hass and `async_will_remove_from_hass
• 57 integrations reference entity_id for purpose other than logging in async_added_to_hass or async_will_remove_from_hass
  • 26 (46%) of those seem to have an assymetry between async_added_to_hass and `async_will_remove_from_hass

[emontnemery]

This was approved in the core architecture meeting 2026-05-07