What a fascinating deep dive. 2x with sphere mapping is my favourite - it starts to take on a sort of pointillism-like quality which gives all the objects (or maybe my brain) a sort of understanding of their texture.
Could be a very useful way to do some overnight tasks using spare RAM. Possibly things like LLM-based categorisation, labelling, data cleansing. That's what comes to mind for me anyway.
I haven't tried it, but I think you could keep the full transcript by running a pre-compact hook (on Claude Code) to save your entire conversation history to a file.
I agree that rejecting valid non-Latin characters in valid contexts is user-hostile, but I should be clearer about scope: this is specifically about machine-readable identifiers (slugs, handles, ENS names) where the character set is intentionally restricted, not display names or user-facing text.
The approach there should be what wongarsu describes below (imo), to style the UI so official accounts are visually distinct (badges, colour, etc.) rather than policing the character set.
namespace-guard is deliberately opinionated for the slug/handle case where you've already decided the output should be ASCII-safe. If your use case is broader than that, confusables detection without rejection is the right call.
Thanks Josh - putting this article out there has pushed me to sharpen a lot of my thinking which hopefully should come across in my more recent work. I've updated the article to scope the NFKC recommendation to identifiers and added a note crediting your correction. Thanks for catching it.
Of course Google can restrict how their API is accessed. But locking paid accounts with no warning, no explanation email, and no functioning support path while continuing to charge $249/month is a different problem entirely. A reasonable enforcement process would have been a warning email, grace period to stop using the tool, then restriction.
What an awful way to lose trust, locking out their users but billing them all the same.