I think I get what you're talking about. Some systems are designed in such a way where the "platform" is formed in two layers: a low level, which exposes a set of primitives; and then a set of abstracting core libraries, implemented in terms of those primitives. Users are expected, idiomatically, to create business logic by making calls into the core libraries; but they're also free to call on the low-level primitives directly. In such a system, the "userland" sits directly on the primitives, with the core libraries as a sibling.

This is the pattern adopted by some, but not all, "runtimes." For example, Erlang has the low-level BEAM VM, and then has the Erlang "kernel" implemented as BEAM bytecode, rather than as native emulator support code. For another example, MOOs (object-oriented MUDs, e.g. LambdaMOO) only had the barest object-graph infrastructure specified in native code; everything else about the foundations of a MOO was defined in terms of objects and classes held in the MOO's state database.

In such systems, you have a sort of "intermediate" level of access to the native API surface, greater than the kind you have from the userland of a traditional VM or OS kernel.

Still, this "intermediate" level of access still doesn't allow you to break through the abstraction layer that the low-level primitives are founded upon. If there are any "complex" primitives implemented entirely natively (e.g. Erlang's `term_to_binary` function), then you can't "break into" that primitive to extend it unless the native runtime has been extended with an explicit "upcall" hook back into the VM userland.