I agree that keep everything on a single blockain is a BAD idea too. So what I'm recommonding is a kind of middle way. Every different core function is on different blockchain(Music, DNS, Play, etc.). But the volatility free currency is from BTSX as source but could be traded between different blockchains. For example, you may have account on both of Music and BTSX, you could top up your Music account with BitUSD by freezing your BTSX account with equal amount BitUSD, and the you could do it in reverse by destroying BitUSD on Music and release equal amount BitUSD on BTSX. It will require additional confirmation time and common Delegates but I think the cross chains trading between Music and BTSX with Music's BitUSD and BTSX's BitUSD will require these conditions too.
As oco101 already alluded to above, what you are proposing is effectively equivalent to the single blockchain approach. You are burdening the delegates of the BTSX DAC to pay attention to the blockchains of all the other DACs that want to use its BitAssets. And not just the delegates, but every node trying to validate the blockchain rules. In order to verify the rules of the BTSX blockchain, clients would need to also be verifying the rules of the Music blockchain to make sure that the same public key did in fact burn the same amount of their BitUSD in the Music blockchain before minting it into existence on the BTSX blockchain. This does not scale well. Communicating this information from the master blockchain (BTSX) to the children blockchain (for example burning assets on BTSX blockchain and minting them on the Music blockchain) is somewhat fine, but doing the reverse process is what kills scalability.
Cross-chain trading allows for communicating this information in both directions without requiring each blockchain validator to be aware of one another's existence. Atomic cross-chain trading means that users can carry out the trade without trusting a third-party with their money to facilitate the trade. Atomic cross-chain trading of BitAssets means that the two parties involved in the trade are not exposed to large volatility risks and that, if the market peg works very well, they can trade 1-to-1 without being concerned about matching bid-ask price (just the amount being traded). There will still be fees to be paid if someone is eager to move their money from one chain to another. My guess is that we will have market makers on each chain who are ready to provide liquidity at a small price. Therefore, it will not be as cheap to move BitAssets inter-blockchain as it is intra-blockchain, but I think it is the best solution we have today given that we want to avoid the unscalable one-chain-to-rule-them-all strategy.
Now, if you really want to find a mechanism to move the BitAssets back and forth between chains without cross-chain trading, I briefly described my idea earlier in this thread on how to do it without it being a total scalability nightmare. Let me expand on it a little.
The BTSX DAC would become a sort of meta-DAC. What this means is that other DACs register themselves on the BTSX blockchain. Shares of the DAC would be issued (sort of like user-issued assets) and people also register as delegates for the DAC while shareholders vote for the delegates using the shares, all happening on the BTSX blockchain. Already this is adding a lot of extra burden on the BTSX blockchain, so there would have to be a limit to how many DACs we would want the meta-DAC to support. It would still be necessary in my opinion to have clones of the meta-DAC to take the burden of every DAC idea under the sun off one single global chain.
Each DAC on the meta-DAC would have a reserve for BitAssets. Users could send their BitUSD held in the BTSX blockchain into the reserve at any time. That DAC's validators could then monitor the BTSX blockchain to credit the user with a BitUSD derivative (let's just call it BitUSD as well) that is pegged 1-to-1 and backed by the real BitUSD held in the DAC's reserve. The DAC's blockchain could then handle the intra-trading of the BitUSD derivative (or whatever other fancy rules it has) without burdening the meta-DAC. But if someone wants to pull their BitUSD out of the DAC (say to spend it in some other DAC), another special procedure would be required.
Because the meta-DAC would not be able to monitor the blockchains of its member DACs, it would need to rely on the DAC's registered active delegates to tell it what BitAsset withdrawals from its reserve are acceptable. You can think of the reserve as a 101-of-101 multisig where the 101 keys are dynamically changing to be the set of 101 active delegates for the DAC. If 101 delegates signed a transaction withdrawing BitAssets from the reserve and going to some address, that transaction would take the money out of the reserve but first stay pending for 24 hours. The reason for the time delay is to give shareholders a chance to "push the panic button" by voting with their shares on the meta-DAC blockchain if the delegates are making a withdrawal transaction that does not comply with the rules of their blockchain. If some percentage (say 20%) of the shares push the panic button, all pending transactions are halted and the delegates are not able to make any new withdrawal transactions until the panic mode has been lifted. If a legitimate crisis did not occur, the majority of share could vote acknowledging that and the holds on the pending withdrawal transactions would be lifted and operation would resume as normal (also perhaps the 20% of shareholders who cried wolf would lose a fraction of their stake). If a legitimate crisis did occur, shareholders would then first change their votes to select new delegates and then the majority of shares would vote to end the panic mode (which would reverse all pending withdrawal transactions, moving the funds back to the reserve) and normal operation could resume with the new set of delegates. The DAC could even have a surety bond paid for by delegate registration fees that goes out as a reward (in proportion) to the first 20% of shares who pushed the panic button (assuming that it was in fact a legitimate crisis). This reward would incentivize shareholders to monitor withdrawal transactions to ensure they comply with the DAC rules.
Notice that deposits of funds into a DAC can be instantaneous but withdrawal would have a 24 hour delay. This is the cost DAC users would have to pay to avoid cross-chain trading. If someone urgently wants to take their money out of a DAC, they could always still use cross-chain trading of their BitUSD derivative on the DAC blockchain with some BitUSD on the meta-DAC blockchain. However, they would have to pay a premium for that convenience.
Also notice that the economic incentives of a 51% stake attack change for children DACs in this model. If someone gets 51% of the stake of a child DAC (meaning they can vote in all 101 of their delegates) they can steal all of the money in the reserve. While up to 49% of the stake (at least 20% needed) may push the panic button, the evil 51% can simply dismiss the panic and steal a fraction of their shares until eventually their stake becomes too small (<20%) to push the panic button anymore. At which point, the evil shareholders would take all the money in the reserve for themselves. A fork by the minority shareholders in the DAC wouldn't work very well in this case because the BitAssets exist in the meta-DAC not in their DAC, so they cannot take that value with them in the fork. This is the other price users have to pay with this model, all for the sake of avoiding cross-chain trading. To be fair, migrating BitAssets to a fork which burns evil stake in case of a 51% stake attack would be a pain for any DAC, so I am not sure how much added risk this model has.