Further discussion amongst the forensic analysis of the vulnerability (I'm talking about Phil Daian's work I linked in the other thread ) suggests it's not just the DAO code that was poorly written but some fundamental assumptions about Solidity which led to the problem and could in future cause problems with any code that calls external code. On the one hand there is a deep discussion about whether blacklisting/whitelisting ethereum contracts and addresses goes against the raison d'etre of ethereum and on the other hand whether the design of the language itself is flawed. Whether these issues nullify the legal gambit of the attacker or just muddy the waters further, who knows.
After reading Phil's post, I don't think the design of Solidity is wrong per se, but that there needs to be more flags for developers intending to call external functions. I am sure that a lot of work is going to go into 'best practices' here after this event.