Resolver logic is counter intuitive when nesting

Proposals
1

Consider the following router

  this.resource('a', function() {
    this.resource('child', function() {
      this.route('new');
      this.route('edit');
    });
  });


  this.resource('b', function() {
    this.resource('child', function() {
      this.route('new');
      this.route('edit');
    });
  });

If I understand ember correctly it expects that a single resource is at the same root level

-- a
-- b
-- child
-- -- new
-- -- edit

But when I look at the above router I expect there to be two different child resources and that the nesting would also enforce namespacing. In other words I expect to be able to create a folder structure like below. And have child behave differently depending on the context and who is its parent resource.

-- a
-- -- child
-- -- -- new
-- -- -- edit
-- b
-- -- child
-- -- -- new
-- -- -- edit

In other words there would be a.child and b.child which are really different things and they would not share the same templates, controllers, routes etc.

From what I understand about ember the way these are registered on the container doesn’t really account for hierarchy in way the containerKey strings are defined and registered.

Is this a conscious design decision? I can see the converse situation of expressing hierarchy in the containerKey actually adds more complexity.

Am I thinking about this correctly?

To be more concrete see this jsbin

http://emberjs.jsbin.com/kixef/1/

I am expecting to be able to do

{{#link-to 'a.child'}}a child resource{{/link-to}}
{{#link-to 'b.child'}}b child resource{{/link-to}}

But ember doesn’t seem to work that way.