Whether the old identifier can be re-registered after deletion needs an explicit policy

What it is

After deletion finishes, the old username, custom short link, and sometimes the email as a primary key inside this product, face a policy choice: release immediately to anyone, hold a cooling period, never issue to others, or allow only the former holder to reclaim. The policy must be explicit means it is written in the deletion copy and in registration-failure copy, so people do not think deleting a username erases it from the world, or conversely that they can come back under the same name. This entry is identifier lifetime. It is not statutory content retention, and not the still-live account during cooling-off.

Why it happens

Identifiers become addresses in other people’s memory, in social graphs and in payments. Immediate recycle lets a newcomer inherit hits on the old short link, misdirected transfers, and old search results; impersonation gets cheaper. Never recycle fills the namespace with abandoned names; newcomers cannot get a readable name. Former-holder-only reclaim needs proof it is still that person, which tensions with a deletion model that already anonymized the account. When email is the primary key, release means the former owner’s mailbox can become a stranger’s account, and old share links that were not killed will point at the stranger. There is no single right policy, but it must be visible before delete and applied by the same rules at register; otherwise the two copies fight.

Studying it

After deletion completes, try to register the same identifier immediately, after a cooling period, as a third party, and as the former mailbox holder, against the written policy.

Independent variables: release rule (immediate / cooling / never / former holder only), whether registration-failure copy explains why, behavior of old short links after recycle. Dependent variables: whether a third party can obtain the old username, former-holder reclaim success, times an old short link lands on someone else’s account, recap of the policy.

Do not use external prices on a “username market” as the study metric. The lab should play both former owner and third party. Old search-engine caches are outside the product; measurement should focus on in-product resolution.

Where it stops holding

Tenant names and trademarked usernames may be legally or contractually unreleasable to others. When a phone number is the identifier, the carrier recycling the number is an external event; product policy must decide whether the old number is treated as a new user. Decentralized identifiers are not reclaimed by this product. During cooling-off the identifier still belongs to the pending account and must not be released. An anonymized internal id and a public username are two layers; copy must not mix them.

Applying it

• In deletion copy, one paragraph: for username, short link, and email inside this product, say immediate release, cooling of N days, never release, or former-holder reclaim only.
• Registration and rename APIs use the same rule; on refuse, say “this identifier is unavailable,” and without enumerating avoid distinguishing “just deleted” from “never existed”—if the policy is cooling, a neutral “temporarily unavailable” is enough.
• Before release, kill old short links or pin them to “this page no longer exists,” so they do not land on a new owner.
• Verify: walk four paths against the written policy (immediate third party, third party after cooling, former-holder reclaim, register during cooling-off). After release, old short links must not open the new owner’s private content. People uninvolved in the design should recap identifier fate before they delete, against the document.

Related

• Within the group: H6.14.1 Data that law requires to be kept must be explained separately · H6.14.2 Data already shared with third parties is not undone by this deletion · H6.14.3 Deletion usually has a cooling-off window during which the request can be withdrawn
• Adjacent: H6.08 Account deletion · H6.01 Registration friction
• Search terms: username recycling · identifier reuse · vanity URL after deletion