There are several globally ongoing problems regarding IDNs (punycode)

I suggest to double check everything regarding charsets.

https://util.unicode.org/UnicodeJsps/confusables.jsp?r=IDNA2008
https://util.unicode.org/UnicodeJsps/confusables.jsp?r=IDNA2003

Looks like there is tough work ahead

Formerly restricted charcodes are now allowed. Its not just a “similar lookin domain” problem, end user could be rightfully typing a wrong uri. (ie. SYRIAC SUPRALINEAL FULL STOP)

Besides IDNs, even young/old highly skilled coders miss this obscure concept, a russian hyphen may pass the string validation without being the same “bytecode” .

Simply put: A russian keyboard config may not input the same hyphen expected in the core, but middleware (app) validating it as the same as the common -

Note that IDN (punycode) is a “new” hazard and it affects domain names and hostnames.
ASCII code validation (user input, source code, etc) is an obscure ole problem that is eternally overlooked, becoming rapidly big nowadays.

Excuse my restless english as well as my lack deep awareness about the whole tech stack.

So I researched a bit further and found a funny note (im familiar with basewhatever, so I felt like indianajones, again).

// Why base-58 instead of standard base-64 encoding?
// - Don’t want 0OIl characters that look the same in some fonts and
// could be used to create visually identical looking account numbers.
// - A string with non-alphanumeric characters is not as easily accepted as an account number.
// - E-mail usually won’t line-break if there’s no punctuation to break at.
// - Doubleclicking selects the whole number as one word if it’s all alphanumeric.

I suggest to do a nice community review to further research on base58. 10 years ago the implementations were few or none, and thus reliable. Now there could be bogus implementations and given the problem also in hostnames (6 types of dots filtered in 2003, 4 in 2008 ¬¬), we have to pay a lot of attention regarding homograph attacks.