Personally I would find this confusing (both as a developer and administrator) for many reasons.

• In places where you don't have the full block log, it is not possible to determine between an expired temporary account and a manually blocked temporary account.
• Blocks on most WMF wikis are intended to be preventative. Meeting this rule often includes not blocking accounts that have made disruptive edits when the edits were made long enough ago and were not serious enough to still justify a block. Blocking zero-edit temporary accounts therefore goes against this general principle. While this is a system block, it could cause confusion as to why we must block (with the associated block log entry) all temporary accounts after a year.
• Blocking every temporary account that expires using a block added to the database seems to me that it would get quickly expensive for the database due to the number of temporary accounts that will be created and therefore about a year later the number of blocks being performed. Could we not create the block on-the-fly based on the authentication state of the account?
  • If we still must use blocks added to the database, we would probably need to use global blocks to avoid having blocks on every wiki for the temporary account (which could quickly get out-of-hand if we did blocks per wiki).

In Special:ListUsers my first point is a problem as shown below:

We could mitigate the first point by modifying the code in the contexts where you don't see the block log to say expired instead of blocked. However, this could easily add complication.

System blocks are not stored in the database (or, if you want, the de facto storage mechanism would be the global user registration date field in this case). Using the authentication state as storage mechanism instead would be probably possible too.

I agree it would be a new and potentially confusing thing, although there is plenty of preventative blocking already for IPs (which temp users sort of are). T358469: Display expired temporary account names differently is a more elegant suggestion but I don't know how easy it would be to implement.

In T359064#9600401, @Tgr wrote:

System blocks are not stored in the database (or, if you want, the de facto storage mechanism would be the global user registration date field in this case). Using the authentication state as storage mechanism instead would be probably possible too.

In theory the configuration of the expiry time could change on a wiki to be shortened, so using the registration date would not be 100% reliable (which we probably need to be if we also end up blocking the temporary account).

Adding this task to upcoming sprint so we can decide if this is something we want to do.

I propose that we do not need to do anything in this task because:

• We will soon be representing expired temporary accounts by placing a line through their username in T358469.
• We represent if temporary accounts are expired on Special:CentralAuth