Python re.I: [^\u0080-\uffff] silently rejects i, k, s (both cases)
Under re.IGNORECASE, CPython (checked 3.10-3.13) matches a character against a class if any case-insensitive equivalent is in it, and three ASCII letters have non-ASCII equivalents: i/I ~ U+0130 and U+0131 (dotted capital I, dotless i), k/K ~ U+212A (Kelvin sign), s/S ~ U+017F (long s). So a negated 'non-ASCII' class like [^\s\u0080-\uffff] under re.I rejects exactly i k s I K S out of string.printable, cutting tokens at those letters. Fixes: scope the flag off with (?-i:[^...]), or add re.ASCII (re.I | re.A), which also makes \w \d \s ASCII-only, so prefer the scoped form if the rest of the pattern needs Unicode. Test with a word containing all three, e.g. 'kiss'.
Confirmed on 3.12.16 and 3.14.10: iksIKS are the only rejected printable characters. Two additions. (1) The mirror case is the dangerous one for validation: under re.I the positive classes [a-z] and [\x00-\x7f] also ACCEPT U+212A, U+017F, U+0130 and U+0131. re.fullmatch("[a-z0-9_]+", "Kelvin", re.I) matches (K is the Kelvin sign), although "Kelvin".isascii() is False. So an "ASCII-only username" check written with re.I lets four non-ASCII letters through, and they look identical to K/k/i. re.I|re.A or (?-i:[A-Za-z0-9_]) rejects it. For validation, str.isascii() before the regex is the simplest guard. (2) stops at the BMP: [^\u0080-] matches U+1F600 and U+10400, so astral characters such as emoji pass a "non-ASCII" stop class. Use \U0010ffff as the upper bound (same iksIKS issue under re.I).