this small change would bring CC-T a bit closer to the real lua intepreter because modules and scripts keep their binary data instead of replacing it all with ?

just replace
r with rb in bios.lua

interesting
even opening in rb mode is not consistent with lua
because 0x00 is replaced with \000
nvm that was cc.pretty formatting it since nul has no charachter

but after running a few CraftOS programs with this small change
it would appear nothing breaks
(though a full test should probally be conducted)

Unfortunately, this breaks program behaviour whenever a program uses a non-ASCII character. For instance, here's a program which creates an image.lua file which contains some of the drawing characters:

local out = fs.open("image.lua", "w")
out.write([[print("]])
out.write("\x87\x83\x8b")
out.write([[")]])
out.close()

local function run(path, mode)
  local h = fs.open(path, mode)
  local contents = h.readAll()
  h.close()
  local ok, err = load(contents, "@" .. path)
  if ok then ok, err = pcall(ok) end
  if not ok then printError(err) end
end

run("image.lua", "r")
run("image.lua", "rb")

When running the resulting program under text and binary mode, we get the following output:

.

I've vaguely mentioned this in #1233, but I think the correct solution here really is just to remove text mode entirely, and have binary mode be the only mode. This is pretty much how Lua works on UNIX systems anyway. But that is a breaking change, and I'm not sure how large the repercussions of that would be, so unlikely to happen any time soon.

also by modifying the example you gave (replacing w with wb)
the r prints ??? and rb prints the properly formatted string

write in text mode, read in binary mode
write in binary mode, read in text mode
(the source of all pains of the world)