@cipherix and @Zach Thanks for your reply and welcome to the forum 
On @Zach ´s argument, changes to Solidity do not have to necessarily lead to changes in the EVM, and hence, not a hard fork. I agree that educating users and programmers is definitely one direction, and a lot has been accomplished in the past two years; for instance, by cataloguing known issues and reporting them (I refer to some of these in the Notable Works section).
It is indeed possible to improve Solidity, the underlying compiler, and even having new languages altogether, while being backwards compatible (at least, from the EVM standpoint). On the first two cases (Solidity + compiler improvements), better static analysis could identify reentrancy cases, as well as integer overflow/underflow. This is not much different that what mythril and slither already do. Alternatively, these could be pushed to the code generator component of solc as a means to generate code that reverts in case any of the two occur during runtime, with the downside of higher gas costs per transaction.
What I would argue is that we do need better languages, with constructs suited for a safe development of smart contracts. Solidity design was heavily influenced by other languages, whose semantics differ a lot (and new developers may assume them to be just the same - an error that can cost a lot of money).
A good research approach to foster the development of new EVM-compatible languages is to plug an EVM-based backend into known compiler frameworks, like LLVM. This has the potential to boost research on better smart contract languages, as researchers would not have to worry much with the code generation part, and redo-it every single time for a new language. In fact, this is the exact proposal of the EVM-LLVM project (https://etclabscore.github.io/evm-llvm-website/), currently in alpha stage.