Added a block inverse register order to test to prove that partial hierarchy matters.

js/test_cases/block_inverse_register_order/alpha.dust

@@ -0,0 +1 @@
+The block content is from {+inject/}{~n}

js/test_cases/block_inverse_register_order/beta.dust

@@ -0,0 +1,2 @@
+{<inject}beta{/inject}
+{>"alpha"/}

js/test_cases/block_inverse_register_order/input1.json

@@ -0,0 +1,4 @@
+{"people": [
+  {"name": "Alice", "item": "cat"},
+  {"name": "Bob"}
+]}

js/test_cases/block_inverse_register_order/main.dust

@@ -0,0 +1,3 @@
+{>"beta"/}
+{>"alpha"/}
+{<inject}main{/inject}

js/test_cases/block_simple/README.md

@@ -5,3 +5,5 @@ Blocks appear to be able to be registered in a loop, however, their context is d
 Even if the surrounding dust would prevent a section from being rendered, the inline context is still registered, which makes me think inline contexts are parsed out in a single pass regardless of the context.
 
 Inline partials in sub-templates do not seem to bubble up to blocks in the higher templates.
+
+After the inverse register order test it seems that it takes the last inline partial with that name at that level, walking up the tree of partials. So each file will have exactly one value for each block name, consisting of the final inline partial with that name. Then when rendering the block, it will walk up the tree just like the context tree.