It is not my fault that many devs still don't get the point between a VM, a language runtime, and how multiple implementations relate to a single language specification.

You know you managed to list examples that are literally case studies of VMs in "Virtual Machines: Versatile Platforms for Systems and Processes", right?

Going through your list:

Xerox PARC worstations: these didn't really run smalltalk in microcode, but ran an interpreter written Data General Nova asm, with the microcode "emulator task" dispatching and executing Nova machine code. There were a few new instructions added for smalltalk, but that was stuff like bit blit instructions. All that being said, even if the smalltalk VM interpreter was pushed down into microcode, it'd still be (a component of) a VM.

The big iron JITing environments are quintessential hardware/software codesigned VMs.

Oberon the language you might have a point, but the secure loader/verifier/compiler in it's only implementation is absolutely a VM.

Java with ART is absolutely a VM, unless you're going to make the argument that HotSpot isn't a VM.

.Net UWP is absolutely a VM too. Yes, it's partially compiled before it reaches end users, but also includes the entirety of .Net core linked in for cases where you're dynamiclly adding new code to your're running process.

Essientially, I think you've come up with some weird definition of VM that doesn't match industry or academia, and then berating people who don't follow that non standard definition.