OK, a few things I see here,
* At the moment we have a Region called `page` which contains all the locators for that page. I presume from what you are saying that we are going to start braking these down at some point?
* I also presume that if we are doing the described above, that we wouldn't be nesting them.
* Also I wonder if you would ever really want form elements to be spanned across multiple regions. We were talking the other day about the FormFiller and that you could have a large multitabbed form defined in one Region. Do you have any use cases for having locators from other regions as part of the form filler?
* I guess there's no reason why people couldn't supply `page.email_text` as a variable and not a string, that would then allow for multi-regioning I think. The only annoyance is having to prefix all locators. We have to think about if multiregion forms are going to be common. I did consider having a kind of tuple arrangement where you could supply a `(region, [locators, ])` kind of deal, but then I realised that this definition is also to define order, which would mean that unless we added some kind of `(region, {locator: key_order})`, we would lose the ordering feature.
* I have already started to define `Table` objects as locators can we do the same for Forms? If the namespace were nested and regions were living inside regions, a Form could be defined at the top level of the root Region and then could use the a string like, `left_panel.emal_text` which could then be traversed? Just an idea.