At first, it's important to understand that all C typedef structs in
SMOP are meant to support Perl 6 features from bottom-up. This means
that the exact same instances of the low-level SMOP will be naturally
available to the high-level implementation that uses SMOP (probably
KP6).

So, the basic structure is:

        all responder interfaces are objects
            ____________________________ 
           |                            |
           V                            |
      SMOP__Object*        SMOP__ResponderInterface*
           |                            ^
           |                            |
            ---------------------------- 
        all objects have a responder interface

These two C types (typedef struct) are the basic elements of the SMOP
runtime, and they implement the features that Perl 6 needs.

Basic Idea

The Object is completely dependant on its Responder Interface, which
is the only ones that knows its internal structure. It knows
how to define which members the object have. An object without a
Responder Interface must be a Responder Interface.

The only fixed thing here is that these two types must be presented
as types in the low-level also, which means that implementing a perl5
extension to SMOP means writing a responder interface object that has
the same C structure as other responder interfaces.

Concept testing

Let's consider we have the yap6_lowlevel_responder that support the
SMOP lowlevel objects, and that we want to create a new instance of
a SMOP__MUTAB__List (which probably will be the default SMOP Array).

We won't discuss namespaces here, only object references, in theory
we can work with completely anonymous objects all the time. The
namespace thing is just a high level helper for it.

SMOP__Object* list_prototype = get_list_prototype();

Now that we have the prototype, we want to construct a new list,
and we do that by calling new, which is the default Perl 6
constructor, but to do that, we need to get the call "new" on the
responder interface.

SMOP__ResponderInterface* list_responder = SMOP_RI(list_prototype);

The method resolution is something that depends entirely on the
responder, so we need to provide with an already high-level compatible
capture object.

SMOP__Object* capture =
  SMOP_LOWL_CAPTURE(list_prototype /* invocant */,
               NULL /* no positional arguments */,
               NULL /* no named arguments */);

Now that we have the capture for the "new" call, we can send a
message to the responder. Notice that the binding and the actual call
will happen inside the responder.

SMOP__Object* result =
  SMOP_DISPATCH(
       interpreter,
       list_responder,
       SMOP__ID__new,
       arguments);

The method new, in this case would probably be the new method for
lowlevel prototype. which looks just like:

sub new ($prototype: |@_, |%_) {
    my $object = $prototype.CREATE();
    $prototype.bless($object, |@_, |%_);
}

And this would behave just the same. The responder would know
to call CREATE on the prototype, and the same for bless. And that's
all. The object is created. bless will call BUILDALL, BUILDALL will
call BUILD where fit.

The Bootstrap

The bootstrap would happen when the high level defines a new prototype
that will have a responder of the higher level object system, and this
responder will be able to implement all Perl 6 object features.

At this point any object+responder can be mixed together, as
in the low-level they will be binary-compatible to the lowlevel basic SMOP
structures.