OWL patches are compiled as standalone programs with stack pointer in a specific address. The firmware copies the generated code to expected address and executes it. Then patch runs until it ends processing next audio buffer and blocks until firmware gets another buffer of audio ready. Patch code is executed inside RTOS thread and firmware effectively controls its execution. Shared memory is used for communication between patch and firmware code (exchange pointers to data, parameters, pass callback functions both ways).
Because of this isolation, only firmware accesses ARM hardware directly. The patch itself contains only the DSP code. When you try debugging it, you can use ST-LINK and gdb with firmware code, but the patch is seen as some blob inside RTOS. The point is, you can’t debug patches themselves (only firmware) and you probably don’t need to make a custom firmware to run a FORTH interpreter on it. With OWL3 (Genius, Xibeca) you can build a patch up to 512kb in size.
There’s no support for serial USB in firmware, but Martin was adding keyboard input a while ago.
Regarding hardware selection, it would make more sense to use Genius as you’ve suggested, simply because it contains a display. Another OWL device that includes an OLED display is Magus, but it’s running with STMF4 MCU rather than H7 as on Genius. As you haven’t ordered it yet, you probably can get a debug connector soldered and the necessary adapter added if you write a comment about it in your order details.
Btw, you’ve mentioned Daisy here and I should mention that I’ve made an unofficial fork of OWL firmware that runs on it. However, none of the supported devices contain USB host ports.