You just need to implement the new Window API on Pi, you can look at any other target's recent changes in Kore to see how it's done. If you're not into C++ though you'll have to wait for sometime next month because I'll currently finishing up some other things with Kore.

I just can't decide whether to update it or disable it via some error message like that. Guess I'll roll the dice.

You can compile Kode Studio for Pi like you compile it for any other target but I tried that and it's just too slow to be usable.

That's because the Pi backend wasn't updated for a while.

So, what's the error?

Please don't use Kha from haxelib, it's completely outdated. Follow the instructions at http://kha.tech instead.

Yes, basically by using update instead of pull you're on the save side. Pull gets you the latest of every submodule.

You get that compile error because you updated the khacpp submodule beyond what Kha itself points to. See "Updating Kha" at https://github.com/Kode/Kha/wiki/Getting-Started - I think I'll keep it like that for a little longer so I can point people to the updated docs, the previous update instructions were troublesome.
Full build tries to compile the generated C++ code but for that to work gradle has to be on your path.

Ha, everything is broken. Are some directory permissions messed up? Looks like khamake is not allowed to run any of the executables (that's what the EPERM error means).

Please use Kode Studio's khaPath option instead of replacing things inside of Kode Studio - it's bound to cause trouble.

The Java problem is known, haven't figured out yet what happened there. More confusingly I currently fail to find where we discussed it before. That generated piece of code is fine though (set_color is overwritten in kha.graphics4.Graphics2) but it shows that you do not actually seem to use the latest Kha but the one in Kode Studio which is a bit old.
Anyways, if you don't have any pressing reasons to use the Java based backend you should prefer android-native, it's much better tested because most people use that one.

Are you talking about the android target or the android-native target?

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.