As far as this paper goes, the main idea is pluralism. Much software lore leans quite heavily on grand narratives about how things "should be done". The "postmodern" view is a reaction against that: in favour of multiple, coexisting, smaller stories. These do not have to be mutually consistent.
Of course there are lots of other overlaps between software and postmodernism in other culture, and that was the wider observation of the Noble & Biddle essay... true that it is a bit oblique. You might enjoy this a bit better: https://www.se-radio.net/2006/11/episode-38-interview-james-... -- it's now slightly dated, e.g. how "programming by Google / StackOverflow" was a much newer idea then than it is now.
Not sure whether you're disagreeing with the paper or the commenter's summary of it. As you could probably guess from the title of the paper, the goal is not a new "fully general" VM.
An analogy I sometimes use is pre-IP internetworking. If you wanted a new cross-network application, then of course you could in principle build application-layer gateways, but the economics simply didn't work. It took a carefully engineered "hourglass waist" to fix the economics. The goal is to create the equivalent for language implementations. And the whole point is that "one super-VM" is not the recipe.
True that the CLR is not mentioned by name, but it is covered. I invite you to read the text again, and especially the following bit.
"Specifically, we should aspire to package language implementations in a way that renounces ‘one true VM’, instead allowing first-class interoperability with the host environment (perhaps at modest drop in performance), the same interoperability with other VMs past and present, and tool support which ‘sees across’ these boundaries."
The CLR simply doesn't do these things, as witnessed by the debacle of "Managed C++" and the usual FFI wrapper tedium of "explicit P/Invoke". It is a classic "one true VM", albeit more language-inclusive than a single-language VMs.
Good question. I agree that endless muddling has shown remarkable mileage.
liballocs is not quite there yet, but is progressing (er, when I get time, which is not often enough). Beyond that, adoption is cultural. We need to build a killer "added value" in one environment which makes enough waves that everyone else wants it. We're creeping closer... with Guillaume Bertholon we have made an initial "FFI-less" for CPython which I think could be the beginnings of that kind of killer addition. You might like to read our workshop paper about that, which I've just made available: https://www.cs.kent.ac.uk/people/staff/srk21/#vmil19
Ouch. :-) There's a lot more to it than that, though wrapping malloc is certainly one part of it. (Reminds me I should finish my blog post on why wrapping malloc reliably is way harder than it should be.)
But the key idea is to avoid introducing new abstractions -- anything that liballocs formalises should be commonly "lurking" in there already. So types and allocators are OK, but apartments would not be. It's not a new programming model... the newness should be at the meta-level only, i.e. ways of describing what existing code already does.
An important bit of context is that this is a talk from the workshop "MoreVMs", which is about -- you guessed it -- language VMs and not systems VMs. In that context, the qualifier is not necessary.
In more general contexts I tend to write "language VMs" explicitly.
Of course there are lots of other overlaps between software and postmodernism in other culture, and that was the wider observation of the Noble & Biddle essay... true that it is a bit oblique. You might enjoy this a bit better: https://www.se-radio.net/2006/11/episode-38-interview-james-... -- it's now slightly dated, e.g. how "programming by Google / StackOverflow" was a much newer idea then than it is now.