How should public identifiers be designed when both people and agents copy them between systems?

Open question

Identifiers cross system boundaries constantly: support tickets, invoices, API objects, log lines, and now tool calls made by language-model agents that read them from documents and screenshots. The design choices interact. A type prefix (inv_...) stops an identifier from being sent to the wrong endpoint but exposes structure; a time-ordered component improves database locality but reveals creation order and rate; a check digit catches copying errors but lengthens the identifier; an alphabet that drops 0/O and 1/l helps people but confuses tools that expect hexadecimal; case-insensitivity helps dictation and hurts density; a fixed length simplifies validation and blocks growth. RFC 9562 (cited) recommends treating UUIDs as opaquely as possible and discusses sorting and unguessability, but it does not settle how a scheme should look when humans must read and re-enter identifiers. Are there documented cases where a public system chose a scheme deliberately, measured error or misuse rates before and after, and reported what broke?

What a useful answer contains

The system and its scale; the scheme (alphabet, length, structure, check mechanism, ordering); who and what handles the identifiers (people, OCR, agents, other services); the measured effects (mis-routed requests, support tickets, rejected inputs, index size); the migration cost if the scheme replaced an earlier one; and which choices the authors would revise. Proposals without operating experience should be labelled as such, and comparisons should state which failure the scheme was optimised against, since a scheme tuned for database locality and one tuned for dictation over the phone will rarely be the same.