From the perspective of someone who'd debugged and traced unikernels from both inside the runtime (LING) and outside the runtime (xentrace), and who worked in the domain of the very z/TPF system you referenced above, the indictment seemed at-best strangely misguided and at-worst intentionally duplicitous.
As you can imagine the indictment wasn't at all persuasive to me, and thus I keep exploring the space in bits and pieces where applicable.
Which is fine if you're upfront about it. He wasn't.
Now, I'm not sure I agree that I have a horse in the race. I don't necessary believe that there is a race. I've never really been a proponent of the schism between Unikernels and Containers. I struggle to see how Unikernels can offer the same flexibility and ease of deployment as containers. We're likely won't be able to support the vast amounts of runtimes and infrastructure needed to replace something like Docker. Perhaps there could be very specific uses where something like the paper described could be used, but I'm not betting on it.
As a software project IncludeOS has a much narrower target than what people traditionally have thought when thinking of Unikernels. And as a result of of this we're not in the business of replacing neither containers not general purpose operating systems(GPOS). We're aiming to carve out a few niches where we are confident that a GPOS isn't the answer. We're only going to address those needs where we're pretty certain we can actually add some value. Basically we're think we can improve on security in addition to adding real time capability whilst still remaining source-code compatible with Linux (mostly thanks to musl).
My grief is singularly with the myths you helped create that Unikernels are something where you are forces to work with stone age tools and hardly without any tools, except printf, for debugging. We've had to spend a lot of time dispelling these. There are a few other things I believe you where wrong about at the time but I'll spare you the details. Better suited discussions over a beer of coffee.
It's not the corner of the sandbox that I play in any longer.
That said, I never really considered Genode in contrast to unikernels to be honest. Something to chew on certainly.
A few years ago someone trying to spin container technology did a lot of damage to other attempts at unikernels with marketing dogma, not reality. Claims of non-debugability and other FUD. It's long been standard operating procedure to trace and debug systems from outside the system's view. This is how people do bringup of new chips as well as OS ports. On hardware there is usually a dedicated debug and trace facility as part of the CPU or board support package or a firmware monitor. In a virtualized environment like a unikernel this is way easier because you can run code above the guest's ring 0 supervisor privilege against its RAM/pagetable root. Modern systems like POWER even allow debugging from the BMC, with a plan to allow full gdb sessions over that out of band interface https://github.com/open-power/pdbg.
There's nothing implicitly wrong with unikernels, or other systems software ideas like microkernels, just because they are less popular technology at the moment. I'd encourage people to continue exploring this space.