>If dotNET creates p-code that "is converted to machine code at runtime", does that make dotNET an "interpreter" as well?

If there is actual machine code being produced at runtime (which is subsequently executed by the "processor"), then that would be a "compiler" (and not an interpreter). More precisely, it would be a JIT Compiler, or "Just-In-Time" Compiler.

Even if the machine code was only generated in RAM, that would still be sufficient. It's the Intel (or whatever) processor that's executing the "code", and not an interpreter (ie. another "program").

In certain circumstances, what is "machine code", could become "p-code" ... depending on the hardware. For example, some (mainframe) computers have emulators that can run machine code that was produced specifically for a different (ie. non-compatible) computer/CPU; the emulator (ie. program) substitutes for the computer being emulated by "interpreting" the "machine code".

On the other extreme, there are programs that simulate multiple virtual computers/machines (eg. VM/370), in which case you could run multiple/different operating systems (and their applications), at the same time, on a single computer, and have them (the OS's) communicate with each other. In this case, there is no "interpreting" going on; the Virtual Machine Supervisor simply intercepts all interrupts/IO operations and simulates multiple (virtual) memories. We're back to running machine code ... at least at the OS level. Similar to Windows and a couple of DOS boxes, but on a much larger scale.