Q:

Is it possible to model inheritance?

My primary source of information for this question comes from a tutorial by James Shore at this address: http://www.objectplayground.com/ ... After rewatching the video several times I took away enough to string together a series of classes, but I still don't really get what's going on under the hood. The way James explained it classical model inheritance (which I assume refers to the use of classes to organize data, rather than an older way of doing things) works like this:
When any function definition statement is evaluated, two objects are created. The first object created is the constructor (which I'm calling cStruct for the purposes of this question), and is identifiable by its member called prototype which according to him and many other sources points to the Function Object Prototype, or Function.prototype. But then it gets weird because the second object created is the prototype (or proType) which in turn is identifiable by its own member called constructor that points back to cStruct, as well as having it's own prototype member that points to the Object Object Prototype, or just Object.prototype. Okay, simple enough (ha!), but then he (and other sources) continue; When one class extends another, we abandon the extending (newer / narrower) classes proType exchanging it for a fresh one which actually points to the extended (original / older / broader) classes proType.
Okay, so by this description I have attempted to recreate the inheritance model using only objects with null prototypes as building blocks, so that I could inspect the results in the console without having to sift through all the stuff I don't understand yet. Basically, I'm looking for the smoking gun of inheritance; proof that it's not just a magic trick. It seems it should be possible but once the logic is established in code form, it not so surprisingly fails to deliver inherited properties. You'll see what I mean.
Common Practice --- Three classes
function ExampleClass_A (  ) {  }
function ExampleClass_B (  ) {  }
function ExampleClass_C (  ) {  }

Literal Interpretation
NOTE These are literally emulated classes. They demonstrate what I understand is going on behind the scenes when classes are authored. On that note, the c variable can almost be ignored until we start extending classes later
a = Object.create( null );
b = Object.create( null );
c = Object.create( null );  // this represents the Object Prototype
cStruct_A               = a;
proType_A               = b;
proType_A.prototype     = c;
cStruct_A.prototype     = b;
proType_A.constructor   = a;
delete a; delete b;

a = Object.create( null );
b = Object.create( null );
cStruct_B               = a;
proType_B               = b;
proType_B.prototype     = c;
cStruct_B.prototype     = b;
proType_B.constructor   = a;
delete a; delete b;

a = Object.create( null );
b = Object.create( null );
cStruct_C               = a;
proType_C               = b;
proType_C.prototype     = c;
cStruct_C.prototype     = b;
proType_C.constructor   = a;
delete a; delete b; delete c;

Common Practice --- linear class extension
EDIT @Vog, I'm not sure what object composition is, but if I had to guess I'd say it was an alternative pattern of class extension / instantiation to the linear one that I have authored in this question, where-in I would have to assume some form of inheritance was taking place anyway. I of course am not prepared to embrace one pattern over another as I'm am simply trying to understand how the mechanism that makes these patterns viable practices in the first place even works.
ExampleClass_B.prototype = Object.create( ExampleClass_A.prototype );
ExampleClass_C.prototype = Object.create( ExampleClass_B.prototype );

Literal Interpretation
NOTE If I understand this correctly, for inheritance to work the proType of all subclasses subsequent to the master class or one another must point to the proType of its parent class. So here we do away with two of three of the classes proType's and replace them with ones that have been pointed to the appropriate "supsequent" location.
a                       = Object.create( null );
a.prototype             = proType_A;
a.constructor           = cStruct_B;
alt_proType_B           = a;
cStruct_B.prototype     = alt_proType_B;
delete proType_B;
delete a;

a                       = Object.create( null );
a.prototype             = alt_proType_B;
a.constructor           = cStruct_C;
alt_proType_C           = a;
cStruct_C.prototype     = alt_proType_C;
delete proType_C;
delete a;

Common Practice --- instantiation
var exampleInstance_W = new ExampleClass_A();   //  
var exampleInstance_R = new ExampleClass_B();   //  randomly chosen names
var exampleInstance_T = new ExampleClass_C();   //  

Literal Interpretation
a = Object.create( null );
a.prototype             = proType_A;
nstance_W               = a;
delete a;

a = Object.create( null );
a.prototype             = alt_proType_B;
nstance_R               = a;
delete a;

a = Object.create( null );
a.prototype             = alt_proType_C;
nstance_T               = a;
delete a;

Common Practice --- assignments
ExampleClass_A.prototype.prop_a = "test a,";
ExampleClass_B.prototype.prop_b = "test b,";
ExampleClass_C.prototype.prop_c = "test c";

Literal Interpretation
NOTE here's where I start to see that something might be wrong
cStruct_A.prototype.prop_a = "test a,";
cStruct_B.prototype.prop_b = "test b,";
cStruct_C.prototype.prop_c = "test c";

//  proType_A.prop_a = "test a";    //
//  proType_B.prop_b = "test b";    //  Kind of cool that this works
//  proType_C.prop_c = "test c";    //

Test --- common practice
console.log(
    exampleInstance_T.prop_a,  //  successful log
    exampleInstance_T.prop_b,  //  successful log
    exampleInstance_T.prop_c,  //  successful log
);

Test --- literal interpretation
NOTE Now for the culmination of all that effort. How confusing that these logs yield different results...
console.log(
    nstance_T.prototype.prop_a,     //  unsuccessful log
    nstance_T.prototype.prop_b,     //  unsuccessful log
    nstance_T.prototype.prop_c,     //  successful log
);

console.log(
    nstance_R.prototype.prop_a,     //  unsuccessful log
    nstance_R.prototype.prop_b,     //  successful log
    nstance_R.prototype.prop_c,     //  unsuccessful log
);

console.log(
    nstance_W.prototype.prop_a,     //  successful log
    nstance_W.prototype.prop_b,     //  unsuccessful log
    nstance_W.prototype.prop_c,     //  unsuccessful log
);

console.log(                        //  Kind of lame that this does't work
    nstance_W.prop_a,               //  
    nstance_R.prop_b,               //  I mean it makes sense when you follow the
    nstance_T.prop_c,               //  established logic, but at the same time
);                                  //  it means that I'm missing something.

In other words, if each Literal Interpretation code block is just emulating the Common Practice code block above it, why doesn't nstance_t have access to .prop_a and .prop_b? Is it something to do with my configuration? Am I missing the point? Help me out guys. Thanks in advance.

A:

Why doesn't nstance_t have access to .prop_a and .prop_b? Is it something to do with my configuration? Am I missing the point? 

It seems like you expected that .prototype sets up the inheritance chain of an object. It does not, it's just an ordinary property, and assigning it doesn't do anything magic.
The actual reference to the object (or null) that an object is inheriting from is internal, often denoted as [[prototype]]. You need to call Object.getPrototypeOf(…) to access it. For setting it, you can use Object.create, Object.setPrototypeOf, or new.
I believe this is the code that you are looking for:
Common practice - ES6
class A {}
class B extends B {}
const instance = new B

Common practice - ES5
function A() {}
function B() {}
B.prototype = Object.create(A.prototype)
B.prototype.constructor = B
const instance = new B

Literal Interpretation (of the object relationships, ignoring the constructor calls)
A_prototype = Object.create(Object.prototype)
A_constructor = new Function(…)
A_prototype.constructor = A_constructor
A_constructor.prototype = A_prototype

B_prototype = Object.create(A_constructor.prototype)
B_constructor = new Function(…)
B_prototype.constructor = B_constructor
B_constructor.prototype = B_prototype

instance = Object.create(B_constructor.prototype)

You can now assign properties on A_prototype/A_constructor.prototype and B_prototype/B_constructor.prototype and see them being inherited on instance.

