#Parent Themes There actually is nothing wrong with the parent/child theme model. I strongly believe that the only kind of theme that should ever be distributed is a parent theme - so clients/devs can create and modify a child theme on top of it.
But I have a problem with developing on top of a parent theme if the child theme is meant for general distribution. Child themes should never be re-sold or distributed.
If I'm planning to build a theme for release, starting with an existing parent theme and building a child theme is a really bad idea.
#Frameworks
Working with the popular theme frameworks is just an extension of this problem - i.e. using Genesis or Builder as a generic parent theme and building a custom design as a child theme on top of it.
First of all, end users can't build a "grandchild" theme on top of my system to keep their modifications separate from mine.
Second, these frameworks aim to be catchall, feature-rich, one-size-fits-all solutions for everyone. They have too many features, too many options, and add too much bloat to WordPress in the first place.
#The Solution
My solution is neither a parent theme or a framework. It's also not really a starter theme, either.
Instead, it's a pre-built foundation upon which a theme can be built. It will contain several pre-built PHP templates to satisfy all reasonable portions of get_template_part() in the template hierarchy. But none of these files will be in the root directory.
Basically, I see this kind of directory structure:
/themes
/theme-name
index.php
functions.php
style.css
/templates
loop-single.php
loop-index.php
... etc
The base functions.php file will include() and initialize a class that will load these template files in a fashion similar to the lock-in technique described here.
Building a theme then becomes a matter of choosing which template parts to load and where. The regular markup for each template is locked in, but can be overridden by placing an equivalently-named file in the theme root.
##Why go this route?
As I build more websites, I find the easiest pattern to work with is one of modularity. Keep things small, keep things simple, keep things separate. Splitting the WordPress theme out into separate pieces and properly using get_template_part() makes it easier to control the finest details of the design.
##Next steps
In my head, this modularity will also extend to stylesheets and skins. My goal would be to make a general starting point for a theme - a collection of default template parts and markup with a base loader class. Then a theme would be built by defining the load order of each template part via index.php and setting up secondary stylesheets in a specific directory.
The loader class will load the default template parts if none other is defined in the root directory. It will also load and concatenate a similarly-named stylesheet.
For example - if a requested page structure is like this:
get_template_part( 'header' );
get_template_part( 'nav', 'single' );
get_template_part( 'loop', 'single' );
get_template_part( 'sidebar', 'single' );
get_template_part( 'footer' );
Then the loader class will automatically look for:
/styles/header.css/styles/nav-single.cssor/styles/nav.css/styles/loop-single.cssor/styles/loop.css/styles/sidebar-single.cssor/styles/sidebar.css/styles/footer.css
It will concatenate the files together and load them all as one stylesheet after loading style.css for the base styles. This allows for very granular control of the layout of every element if needed.
##Other Design Principals
I hate theme options with a passion.
A theme options page is yet another page cluttering my admin panel. After I install a theme, I never touch them - so keep options and control in the theme design rather than in the UI.