Much of this is not essential complexity, but accidental complexity.
* Based on the data they identify - This is a minefield of accidental complexity. Data changes and needs to be redacted for GDPR and other data laws. What do you do when someone demands you delete all personally identifiable data but you’ve burned it into invoice ids that you need to retain for other legal reasons? This is also begging for collisions and very much at odds with making IDs short.
* easy to remember - This is a nice to have. Short is convenient for sharing on the phone. Memorable didn’t matter much. I don’t remember any invoice number I’ve ever received.
* versioned - Versioning is only interesting because you’re trying to derive from real data. Again, accidental complexity.
* easy to index - Sure.
* sortable - Nice to have at best.
> * Based on the data they identify
> * easy to remember
(which means human readable and related to the actual information which makes them easier to remember)
These actually are the most important features.
Example: transaction references not related to the actual subject of the transaction (ie. what is being paid for) is enabler for MITM scam schemes.
> Short is convenient
Nah. Short is crucial for identifiers to be effective for computers to handle (memory and CPU efficiency). Otherwise we wouldn't need any identifiers and would just pass raw data around.
> * versioned - Versioning is only interesting because you’re trying to derive from real data.
Nah. Even UUID formats contain version information.
> * easy to index - Sure.
> * sortable - Nice to have at best.
These are directly related (and in the context of UUIDv4 vs UUIDv7 discussion sortable is not enough - we also want them to be "close" to each other when generating so that they can be indexed efficiently)