Primary keys using UUID v7 are potentially an HR violation (mikenotthepope.com)

I suppose you can infer, very roughly, that a UUID with an older date stamp inside it is possessed by an older user ... very roughly.

At the same time age of account is all over forums and other places, often used to demonstrate a certain level of trust vs say new accounts.

Is that also a privacy issue? I'm not sure I like the implications if it is.

If this is well-known, won't applicants create new accounts instead of ever using the old ones? Like unsold houses, if they're on the market too long, the listing will be removed and a new one will be created instead of dropping the price to maintain that illusion of a new listing.

The encryption implementation suggested seems overkill and problematic as it increases the size of the ID. UUID is 128 bit which is the same block size as AES. You can simply apply AES to transform the input block with a secret key to and directly expose the result. No need for CBC mode or IVs etc as it is desirable for the same input to map to the same output all the time.

Don't expose primary keys to the public. Create separate external ids instead. I personally use BIGINT primary keys, with UUIDv4 external ids, but any random string will do.

Job history, education history, actual date of birth capture, military service etc are all other parts of applying for a job generally speaking and can also determine if someone is "old" ... as an older guy, I myself have seen a lot of shift the closer I got to my current age of 50yo.

UUIDv7 isn't exactly the compromise it's made out to be in the current context.

External IDs shouldn't contain any metadata, UUIDv4 should be used for those. UUIDv7 is suitable for database primary keys when simple incremental IDs are not sufficient, but primary keys should really never be used externally.