The 'cl' function in c/lil.h clamps bytes to ASCII, replacing other characters with '?'. The 'clchar'/'clchars' functions in js/lil.js do the same. The 'str_add' function in c/lil.h also skips multiple-byte codepoints when filling strings, which happens with `read["somefile"]`
So with a few changes to stub some of this out, you can get a Lil that "just slings bytes around", but there might be a few landmines still with other code expecting the clamped values.
If Lil would at least just sling bytes around without mangling them, then I could embed lil.js as a more approachable data-exploration language in a work website, or use lilt for a foreign language TUI flashcard program. As it is even `write["out" "тест"]` will write ???? to the file, and `"тест"[0] = "?"` is 1. This feels like an active limitation, that lil is taking extra steps to implement, which limits its use a lot for me when I find it very interesting as a Q-like language.
In Decker, it could be a requirement that *displaying* strings clamps them to the bitmap's range, which mangles unicode only on display - which gives the programmer a chance to map intended ranges of non-ASCII characters to a displayable range.
