Global vs Local Block Ordering in Context UI

== Typical problem: ==

Imagine a use-case when two or more contexts overlap (conditions for both are matched). If both context definitions assign some blocks to a region (let's assume it's Left Sidebar region) a sum of all blocks from all active contexts will be displayed in the Left Sidebar. That's very cool. What is not so cool, though, is that the order of the blocks in the region is [almost] unpredictables. Now, for full fairness, the order is not totally random, but it's nothing intuitive either and the order can not easily be controlled from code or from a UI.

== Give Us Order! ==

Having an ability to manually order merged list of blocks in overlapping contexts would be nice... Well, it's not that easy. Number of possible overlaps can be too large for any reasonable UI. In addition possible overlaps can not always be predicted during configuration. Context conditions can by anything (including something that is unpredictable before run-time).

== What to do? ==

Well, as in most things in life, we don't need an over-engineered solution that works in 100% of cases. Something that solves 80% of cases, but does it elegantly would be fantastic.

== Proposed Solution ==

Let's have two "orders" for blocks in a region:
1) Local - in effect when blocks from only one context appear in a region.
2) Global - in effect when blocks from at least two contexts try to occupy a region.

== User Interface ==

Instead of one list of blocks, have two tabs:

1) Local (default) - pretty much exact same thing as what Context UI has now. Only blocks from context being edited are shown and user can order them with drag-n-drop.

2) Global (second tab) - blocks added by current context definition + all blocks from all contexts that are added to the same region (in other context definitions). Initial order: alphabetical. Can be re-ordered with drag-n-drop.

== What does this solve ==

For cases when only one context tries to populate given region (even if there are other contexts active, all we should care about is whether specific region has blocks from more than one context) everything will work like ti does now.

For cases with region being populated by blocks from multiple overlapping contexts we will have a Global order to refer to (predictable behavior).

== What this does not solve ==

Complicated conditions like: if Context A and Context B overlap then order should be X for Left Sidebar, but if Context A and Context D overlap order should be Y.

However:
1) such overly detailed instructions are much less common
2) UI would be so sophisticated that it's a fair trade-off
3) A new hook can be introduced that allows modules to fiddle with block order programmatically, during run-time.