Fiery

Young children should absolutely not have a phone, unless I suppose it's completely locked down to chat apps and the tracking I suppose...

Depends, the EU seems to actually have a decently prepared system, using zero knowledge proofs. If it's that, my privacy would not be harmed, but would still prove I'm allowed to view the page.

As for the situation where every site needs a photo ID, I might just go live in a cabin in the woods or something

Edit because I'm being downvoted: I do not support the idea of locking down parts of the internet behind any kind of identification. The question is "what would you do if it happened" not "how would you like to see it implemented".

Do bank frontdesk workers work by commission where you live or something?

There's extensions that get rid (/autoclick) of those banners. Eg "I (still) don't care about cookies"

Problem is that good sites, which do not do all the garbage listed above, do not get rewarded for that when being consumed through AI. And in that case you should in fact feel bad

8. You're not a criminal, but you fear the definition of 'criminal' might change in the future

Technically even the standard system is also AI (and it totally would've been advertised as such too before the LLM-boom).

Both versions above actually are part of the ISO8601 spec though, as week dates and ordinal dates.

How about 25-206 or 2025-W30-5.

Edit: the ISO8601 spec includes these

No matter the argument for or against allowing a game, the role of deciding this should not fall to a payment processor basically holding a game platform hostage.

Functional programming fixes the problem by simply not making it OO anymore, and while I'm personally a big fan of the paradigm there are situations where an OO approach is preferable (or even only to conform to a project's existing way of doing things).

Not like C# is all that much better. So much garbage in the fundamentals just because it was done that way at the start and "they can't change it now". The best example is the IList interface.

Theoretically this interface exposes both index-based access and collection-like modifications and as such would be perfect in a function if you need those two features on a type. In reality you can't use it as a function parameter because half the official types implementing IList aren't modifiable and throw a runtime error. E.g Arrays