The alias and the data stored under it can disappear. Deleting an alias purges it from the network, including the data nodes stored under that alias.
This is not the same as a user logging out. Your application should not assume that the alias will return later or that its previous application state can still be recovered.
Design for absence from the beginning. If the application requests data for an alias that no longer exists, it should show a clear empty state rather than failing or exposing a technical error.
Keep context-specific information on the alias. Most application state belongs there because it relates to one context. Information that is genuinely central to the person across different contexts may belong on the Core ID, but Core access should not be used merely to avoid deletion.
Do not silently reconstruct personal data from another source. If a user deliberately removed an alias, creating a replacement profile from tracking or another identifier would undermine the privacy boundary the alias provided.
Be careful with immutable data. An immutable node can block full account deletion until the application provider removes it. Use immutability only where permanence is a real requirement and provide a working process for deletion requests.
The product rule: Your application must continue to operate safely when user-controlled data is removed. Ownership includes the ability to leave.