I know it's common, but please stop calling reentrancy bugs "race conditions". Smart contracts don't observe concurrent modification of state by other contracts and aren't internally concurrent. Solidity and the EVM object model have way too much implicit behavior, which can lead to unexpected control flows, but these unexpected flows aren't the result of other threads coming in and mucking up state.
Calling a simple reentrancy bug or spookily unexpected control flow a race condition lets the Solidity and EVM designers off too easily. Concurrency with shared mutable state is always difficult, but Solidity makes even simple single-threaded reentrancy difficult to get right. (On a side note, I'm a big fan of Actors/shared-nothing concurrency and think raw threads are almost always the wrong abstraction to expose to application-level developers.)
I also totally agree that Turing completeness is overkill for 99% of use cases, leading to bugs in simple contracts and makes analysis very difficult. If you really need Turing completeness, you could still explicitly construct it within a sufficiently expressive declarative non-Turing complete execution model via externally triggering repeated contract invocation. (For instance, a Brainfuck interpreter that advances one program step per contract execution.) The ecosystem would be Turing complete without contracts being Turing complete.
The possibilities are endless. You could have pre-chosen adjucators that can upgrade a contract on majority vote. You could use a decentralized prediction market like Augur to trigger a contract upgrade if it deems that certain events occurred, etc.
Upgradability is just one component of many that will be needed to create a durable/secure smart contracting system. It's not a silver bullet.
>>The Etherium promoters want this because they botched the design.
Do you misspell Ethereum deliberately? I only ask because I've seen you comment multiple times about Ethereum with this misspelling, which comes across as very petty.
>>The DAO debacle, and this latest demand for a "state change" because someone botched a big contract, indicate that.
The latest state change request is overwhelmingly rejected by the community and will not happen.
The request is only possible at all because of the temporary state of Ethereum having several hard forks planned that a state change can be snuck into.
Once this phase of its life cycle is over, even requests for a state change will not happen.
>>Smart contracts should have been in some declarative form like decision logic tables
The point of using byte coded programs and a Turing Complete execution environment is to make features like the smart contract programming language totally configurable, rather tied to a single base implementation.
Lots of people don't seem to appreciate this.
That's perhaps a too strong statement. Bitcoin's smart contracts are byte coded programs too, and have had none of these problems. Perhaps partly because a lot of the instructions were pruned early on, and only those deemed absolutely necessary for the kind of contracts that made sense were kept.
The article has full details on how to create a contract changeable by one party, then hand waving about "writing a contract that uses tokens and voting mechanism to allow the community to decide whether to update or not." No details on how that's supposed to work. Who's "the community", anyway? The parties to the agreement are the ones involved.
A mechanism where all parties to a contract could agree to replace it with a new contract would be useful. That's a normal contract activity. You do that whenever you renew a lease.
The Etherium promoters want this because they botched the design. Smart contracts as byte coded programs are too error prone. The DAO debacle, and this latest demand for a "state change" because someone botched a big contract, indicate that. Smart contracts should have been in some declarative form like decision logic tables, not Turing-complete programs with race conditions.