gambitph
Framework embeding logic
In your documentation on embeding the framework you mention that if the plugin version is ever activated, it will switch to using that version. IMHO one of the points to embeding the framework in the first place is to use custom versions of it. So if my modified version just switches to the official plugin version, evertything will break. I propose to make the switch optional. There should be a flag inside the framework for optional switching to the plugin version, and also a flag for the developer to know which version of the framework is being used.
The problem is, Titan is defining about 40 classes, and if you want to keep your Titan version separate from the Titan plugin installed, you need to have unique class names. (meaning you need to rename those 40 classes to make them unique) It's not difficult. However, I don't think you need to do that. The object-oriented structure allows you to easily add your custom option types (you just need to include an option type class in your theme which extends TitanFrameworkOption).
It might be more trouble than its worth, seeing we update every now and then, but there are ways, as @ardalann has mentioned.
For me personally, embedding enhances packaging but it should not encourage modification. For example, if you're going to create a relatively small plugin and you still want to create settings pages for it, then embed Titan so that your users won't have to install 2 plugins instead of 1 just to make yours work.
We don't encourage embedding then modifying it though. Because there will be new features, bug fixes, etc; if Titan was modified, then it would be a huge pain to add those new stuff into your modified copy.
So for example, you created a premium plugin that has an embedded TF. Then one of the customers finds a bug with TF. When there's an update to TF, then you can simply tell them to install Titan from the repo and the bug should be gone. You can just update your own embedded copy on your own time :)
Why not namespace all the classes to PSR-0 standard? this would overcome all the class name conflicts?
Also if composer was being used properly we would only need to require it in our composer.json file and not call theme embed php script.
As per my other comment, namespacing is not practical in a distributed WordPress environment. TF is on the plugin repo. IT must be compatible with core PHP requirements (5.2.4 currently).
And ditto for composer. Also, you should never make your users have to do a composer update in a bundled community package! Private or narrow-focus code? Sure. You can control the Server environment. But not on, say, a shared host in Morocco.
