The v6.1.1 toCharCode rewrite (#79) assumed every Char value is a complete UTF-8 sequence and unconditionally read c:byte(2..4). But Data.String.CodeUnits slices a String byte-wise (toCharArray = s:sub(i,i), one byte each) and lets Data.String.CodePoints reassemble code points, so toCharCode is routinely called on a single byte that is the lead/continuation byte of a multibyte char. On such input c:byte(2) is nil → attempt to perform arithmetic on a nil value.

Reproduced via the StringCodePoints eval golden (CI), which crashed at runtime:
golden.lua: attempt to perform arithmetic on a nil value … in function 'toCharCode'.

Shipped in package set psc-0.15.15-20260615 (enums v6.1.1). Fix: length-guard the decode — only assemble the full code point when the whole sequence is present (#c >= expected), otherwise return the lead byte (the old byte-in/byte-out behavior the CodePoints layer relies on). The Char-literal decoding from #79 is preserved. Regression test adds lone-byte cases. Fixed in enums v6.1.2 / set psc-0.15.15-20260615-2.