I had just looked at pixopoint.com's offering the other day - although my analysis was not clearly as in-depth as John's. Definitely it's "feature full".
For myself - I find the filter-hooking method a tad "oblique" and less than self-evident. Until I landed here - I had never seen it done that way...A plugin would really add something in my view - as have all of the other recent contributions you have made toward "building a better mousetrap".
I'd like to promote the idea concept of potentially having ANY of your new plugin development provide Hybrid-specific capabilities - either during configuration or execution - or both.. For example, maybe that once configured - there could be some means to export the configuration in an XML form (or something else) so that it could be "reloaded into another Hybrid-based environment which would replicate all of the settings. Alternatively, perhaps when loaded into a Hybrid frame-based environment - Maybe the configuration could be done via some ajax-driven drag-and-drop interface.
Second, it seems that the more capable and selective the configuration is - especially with things like menus - the configurations becomes awkward and complex for end-users - largely because the capabilities integrate "deeper" into WordPress, making fewer assumptions.
Maybe the solution for this is to provide some sort of "tiered" configuration - based on the sophistication of the user - Either self-selected - or alternatively - Maybe - all plugins could "look for" the presence of some other Hybrid construct (maybe a designer/developer plugin? or mode?) that would enable the more extensive capabilities at configuration..
Maybe it would then be possible to lock-down the configuration - so that the end-users could make cosmetic changes - but not trash their sites - or correspondingly - the developer/designer could "unload" their plugin after the configuration was complete - that would remove capabilities that would be otherwise get inexperienced users in difficulty. I think it would be great to have a drag-and-drop interface for both sets of users.
Alternatively you could have "fat" or "skinny" versions of the same plugin - one with a great and expanded configutation mode - that would produce configuration information - and another "skinny" version the would simply execute based on the previously instantiated configuration information. Maybe the "skinny" ones work on ALL platforms and the "fat" development versions only work on a Hyrid-based theme - so that if you want the advanced capabilities configured - you must configure it "under Hybrid" - but once done, it will execute the same in ALL themes.
I think that either of these basic ideas will provide incentives for users to move in your direction - either toward your plugins - or theme framework - or both... Things should be "easier" or "better" using Hybri - But that means different things depending on whether you're and end-user or a designer/developer. Designer-developers want deeper, more feature-full implementations - that expose more WordPress capabilities - and inexperienced users want the flexibility of making changes - but without the risk of "messing things up". I also think it would promote a constructive dialog between end-users and develpoer/designers in that they could exchange Hybrid configuratons with would be guaranteed (by design) to work correctly without the latter having to have direct and contemporaneos access to the end-user's site.
Finally, I'd like to see all of the plugins support properly degradeable Ajax-JQuery in some manner. I'd like collapsible lists or other capabilities to be configurable in the plugin itself - and not require yet anther "piggy-based" plugin to alter the behavior of the former. Since you control the basic styles under Hybrid - that should be possible - I imagine.
I'd like to see "Hybrid" branded WordPress components work "better" than their counterparts - by design - Such that they are preferred.... I think there is some room to add something to the basic architecture that will be of value to each of the already identified constituencies...Something that WordPress itself has largely avoided - leaving it to "Ace" developers to sort-out.
