You can read Franz' PhD dissertation on it here[1]. While it's reasonable to describe it as serialising an AST, most of the Oberon compilers of the time did not have an AST per se, and so what you serialize is entirely arbitrary to your choice of node types, and the operations used by the Oberon version are low-level enough that while some work would have needed to be done to be generic enough if one wanted to more easily support other languages, it's largely moot. There's no large semantic gap between what is serialized and the generated code.

At that point it's no different from with Java - if you add new bytecodes, the JVM needs to support it. Same here - if you add new node types, the code generator will need to support it.

Just as you wouldn't change the JVM bytecodes for every language change, you likewise wouldn't need to add new node types to support most language changes for Juice either. You could just as well choose to generate what in effect would be an intermediate representation instead. You'd only add new node types if they provide a sufficiently big win over generating more complex output, just as with the JVM

That said, nothing would've prevented dynamically updating the code generator.

[1] https://oberoncore.ru/_media/library/franz_m.code-generation...