I'm not sure that I got your idea fully but I think that you are on the right track in terms of separating "smart contracts" into several more or less independent components. I tend to believe that an architecture of loosely coupled components in which each components is responsible for a small and preciese operation works better rather than one-big-blockchain-to-rule-them-all (like Ethereum).

The most straigtforward is to separate (as I see it)

- messaging (ability to exchange messages among contracts)
- storage (e.g. sql/no-sql for contracts = simple application server that only supports CRUD operations)
- execution (buisness logic of contracts = application server, Codius can serves as an example)

I'm currently working on a toy project (which derives heavily from BitMessage ideas) that concerns messaging.