Just a quick answer. It is very simple, and thought out-of-the-box. First a short intro.
Templates are used to tie a layout together, currently. One would expect the following template available (but it isn't yet):
Text Formatted Code
template index.thtml (or page.thtml):
{header}{body}{footer}
We'll find a header.thtml and a footer.thtml, but no body.thtml.
Text Formatted Code
candidate template body.thtml:
{left-blocks}{center-content}{right-blocks}
GeekLog Core assembles the blocks for left and right and the plugin creates the center-content. A template is used by glCore to avoid coding in php.
The concept is that one ties a template to a layout (by name) in stead of defining the layout inside the template, as shown above. The confusing part is that a layout is a structure of templates. My view is that glPage maintains a array with elements that identifies a layout and the php-code refers to these id's. Well, not exactly a array of id's but merely a tree of layout components. Valid id's would than be (long form): header, body, body:left, body:center, body:right, footer. The coder would assign a template to such id as opposed to creating a template and assigning the finished content to a variable in the main template.
Example: A plugin could create id's like header:search or body:left:search and assigns the search-box.thtml template to it.
To answer the questions:
A page consists of several boxes (rectangles). We might group them by function, topic, security or else. Important is the grouping by position on the screen (the layout).
Now, every box must be seen as a page too and glPage assembles all those 'pages' into a layout (a page too). A tree of pages is constructed in memory, and every page can have many child-pages and has exactly one parent-page.
A skin is a skin; a theme consists of one of more skins; the current skin is applied to the layout it is set for. In extremum 'header' could be orange skinned, 'body' blue and 'footer' light-green. Additionally the skin of 'body' could be customised too: 'left' could be pink, 'center' dark-red and 'right' mint. Skins cascade as css does.
A theme has a default layout which is identical to the geekLog default layout. Since a layout is a template, the theme might adjust the default templates (or not) for this layout.
GeekLog 'knows' about one layout: page: [header, body: [left, center, right], footer] which happens to be the concept of GeekLog. The new glPage class knows only one layout, and custom layouts can be attached to any component of the known layout, building it's own themed and skinned pages.
Maybe a theme would be able to configure the layouts to use.
For selective blocks there will be no changes. Though it would be wise to rethink that.
The file structure of a theme would be better change, since it is a extensive melting pot of all kind of ideas, some smart, some obsolete. I do think that the directory-name of a theme is of no interest to the plugin and must be magically discovered by glPage.
A bigger problem is that a lot of code generate html attributes scattered all over the place.
These should be in (theme) templates because that is the first principle.