Even BitShares would eventually have to be reinvented as a turing complete block chain, and the hard coded market pegged assets would likely have to be replaced by scripted MPA's, in order to streamline and optimize everything.
I disagree with this. You don't want to put everything on the slow VM. You want certain things written natively so that they are accelerated. Certainly there is a huge place for Turing complete scripts, but there is also an important place for native features. I think what is really important is to have a good method of coming to consensus on feature upgrades that are requested to be developed, and then a binding way to vote for the hard fork features to activate on the blockchain (this would obviously only happen after enough people have upgraded to the new clients supporting those features).
Before I bothered to understand it, I'd always imagined that Ethereum, as this "gimmick turing complete fancy little block chain for nerds", would end up becoming a sidechain of BitShares, where all the useful stuff could then be put on the primary BitShares block chain.
This sidechain idea is still valid in my opinion. You can pay for all of the Dapps running on the blockchain specializing on general purpose computation using BitAssets that derive their value from the root DAC in which they are shorted into existence and collateralized by BTS. That is what I propose
here.
Now I personally don't think we will be able to achieve consensus between BTS and ETH stakeholders and join forces. But let's say it was possible. We would need a way to negotiate the terms of the merger. Simply arbitrarily picking percentages or having negotiations between Dan and Vitalik isn't going to cut it. The stakeholders need to come to a consensus. So I suggest the following method if you did in fact want to go through with this merger:
We modify the BitShares codebase to allow for BTS stake to also vote for a percentage between 0% and 100% in addition to a delegate slate, and update the BitShares client to this new codebase. We launch a DPOS no-BitAsset clone of this new BitShares with the genesis allocated to ETH stake (call this ETH'). We would have to convince the Ethereum community to import their private keys into the client and use it to vote for their preferences with the understanding that if the merger goes through their original ETH allocation will be worthless and this new ETH' will end up having value (at least temporarily until it is snapshotted into yet another token). BTS holders will be voting for the smallest percentage allocation in a new combined token (call it BTS') that they will accept, with the remainder being distributed to ETH' holders. Similarly, ETH' holders will be voting for the smallest percentage allocation in BTS' that they will accept, with the remainder being distributed to BTS holders. This gives us a distribution of each community's stake over the percentages they each accept in the new combined token. We search for the percentage breakdown that maximizes the sum of the percentage of stakeholders approving of that breakdown for each of the communities (with equal weights for each community in the sum). If the lesser percentage of stakeholders approving of that optimal breakdown between the two communities is larger than X% (I suggest an X = 75), then we go through with the merger. If after some point in time (after people change their votes back and forth and stake ownership shifts around) the previous condition is not satisfied, then we give up on the idea.
If the merger is to go through and we have our consensus percentage breakdown, we can then hard fork BTS to BTS' (with its new stake allocation) and let the previous ETH' holders (who were previously ETH holders) join our community with a fungible asset we all share. At that point, the Ethereum devs and their crowdsale funds follow along with the community. At some point, when the Proof-of-Stake version (ideally using DPOS) of Ethereum (with BitAssets added) is ready, the client can hard fork again from the BitShares client to that new Ethereum client. We can also rename BTS' to something else and do an overall rebranding to something else (decided by BTS' stakeholder consensus).