The krom.js.temp file and the krom.js file are the same files, --debug just creates the .temp file so it can then do an atomic update to the non-temp file which helps with the broken hot-patching support.
Did you try setting a breakpoint in the js file? It should of course also work in the Haxe files but it would help to pinpoint the problem.

It's just me learning Verilog, right now it's an integer-only MIPS CPU and a framebuffer. Maybe one day it'll actually run Kore programs but the main target is for me to learn more about CPU and GPU internals and to then use that to make Kha and Kore faster.

Didn't know about this and it's very interesting. Maybe windowed Metal somehow introduces another buffer before things end up on the screen. Please create an issue on GitHub. Maybe I can set something up to measure that.

Your khamake call is essentially the same that Kode Studio does, so that's just something that was fixed after the last Kode Studio release. The --debug argument is also not helpful in that situation I think. Address already in use also just means what is says. Kode Studio randomizes the address so when it's already in use, just try again. And what's a CL? And do the breakpoints work when you set them directly in the generated js file? Is the debugger even connected?

None of that is needed - the launch config is created automatically, Kha is included in a version compatible with the version of Krom which is included and your Haxe installation is just in general ignored by Kha which uses its integrated version of Haxe.
So - what exactly happens when you try to launch a Krom debug session?

There is no detailed API documentation.

beginFace is used to render one face of a cube map, beginEye is used to render one image of a stereoscopic display.

Well, that sounds fun. Add an issue on GitHub please.

Ya, but that's not what one would call "working normally" str.charAt should just work, Utf8.whatever should only work on things which are explicitly utf8 (normal Haxe string nowadays are not). I will get to that (or I'll just bug Hugh about it).

str.charAt should work, will look into that. Utf8.whatever is only properly working after you used Utf8.encode I think. Maybe. No idea if the thing is up to date at all, docs still talk about iso strings, whatever that might be.