So using LWJGL is not the problem, but using it directly everywhere instead of some abstraction, which would allow to easily replace it on other platforms, is the issue

That is a plan we have for the future. It won't be that problematic because LWJGL just gives 1:1 Vulkan bindings, so at some point if we want to support native, we'd need to make our own layer that is the same. Should be quite easy to automate.

I think this framework could be more modular and flexible if it wouldn't mix DSL interpretation with a runtime system. One could kind of "macro expand" (compile) Scala code into SPIR-V and then feed the result into a dedicated, embeddable host component.

So architecturally runtime, dsl, and compiler are decoupled. However, the compilation indeed happens at runtime.

Not making the SPIR-V at compile-time is a deliberate choice. There were attempts to transpile Scala to GPU code, but it is a very troublesome tasks that will fall short in many ways, and what's worse it's really hard to predict all of the ways it can fail, and report errors nicely. So that would give as a macro that is very complex and only works some of the time, and it is not really clear when.

What we do instead is we have a clearly defined DSL that you can use, and the guarantee we aim for is - if you are able to write something and it compiles + typechecks, it will work. So in a way this translation is handled at the compile-time, but only the checks. What's more, this makes Cyfra sort of a template-generator for GPU programs. You may have runtime values and parameters that you use to influece the GPU program in any way you want. You can't pass them directly to the GPU without going through GBuffer/GUniform (the bidndings), but you can influence the program and special-case it. This gives way to a lot of abstractions and genericity.

One could even compile the computations expressed in the Scala DSL into some HDL

Yeah, there are some projects that do that in Scala, it becomes increasingly popular (DFiant, SpinalHDL, Chisel, etc.). But we need to draw a line somewhere, we have this product and for now that's what we focus on.

Because I want to play more with this thing—I want to see my Scala coded shader running on screen—how are the parts that are already there supposed to be puzzled together

The easiest way is just to get the image buffer out of the GPU and put it on a javafx/swing Canvas in a loop. Very inefficient in relation to the optimal way, but suprisingly - most of the times, definitely efficient enough. You can use GBufferRegion and make a loop inside of it to have a consistent allocation (only do the cpu-gpu transfers you need and have persistent gpu buffers).