"The difference is that those systems did not solve the "double-spend" problem"
Can you define "double-spend" in a precise way without a central authority? Academic systems define double spending in terms of the bank -- loosely, a double-spending attack is successful if the bank accepts more money for deposit than had been withdrawn; security against double spending is defined as the inability of any polynomial time algorithm to successfully double-spend with more than negligible probability. Note that this definition makes no mentioned of how this security is achieved, nor does it bound the number of users the attacker can control (indeed, the attacker could control all parties other than the bank under this notion of security). The definition is slightly weakened for systems that support secure offline transactions: (loosely) if and only if more money is deposited than is withdrawn, the bank will be able to identify the parties involved in the attack and can prove that those parties acted maliciously (in a way that can be verified by all other parties).
In the case of Bitcoin, you cannot make any statements about deposits or withdrawals if you try to define security. It is also unclear how one might define security, since there is nothing wrong with a party that spends more money than it receives (due to the mining protocol). At best we can only speak in vague terms and vague notions of what should happen in Bitcoin versus what should not happen with Bitcoin.
"Bitcoin is the first ecash system that is truly decentralized."
That is debatable. On paper, Bitcoin appears to be decentralized, but on paper Bitcoin scales extremely poorly. To make Bitcoin scale well, someone occasionally declare a particular branch of the block chain to be the block chain, and all the users must accept this judgment. That is basically what happens now; the Bitcoin developers ship a client with this snapshot state included.
If you doubt the power that the Bitcoin developers have over the network in practice, consider the block chain fork a few months ago. That fork was triggered by an update to the "official" Bitcoin client (worse, it was not even caused by a "snapshot;" it was caused by a seemingly harmless deviation from how the previous client worked). In practice the Bitcoin developers could trigger another fork at any time, and could potentially profit by it.
"This is what makes it technically superior to prior systems"
Except for all the technical deficiencies. Even if we take as an article of faith the fact that Bitcoin is fully decentralized, even if we ignore the complete lack of a security definition, Bitcoin has technical deficiencies compared to academic systems. No support for secure offline transactions limits Bitcoin's usefulness in real-world applications. Enormous amounts of computation are needed to keep Bitcoin running, vastly more than are needed in academic digital cash systems. Academic systems have rigorous anonymity guarantees (except for "cheating" users); Bitcoin has no such guarantee and requires someone to operate a "mixing service" to provide some kind of anonymity.
Can you define "double-spend" in a precise way without a central authority? Academic systems define double spending in terms of the bank -- loosely, a double-spending attack is successful if the bank accepts more money for deposit than had been withdrawn; security against double spending is defined as the inability of any polynomial time algorithm to successfully double-spend with more than negligible probability. Note that this definition makes no mentioned of how this security is achieved, nor does it bound the number of users the attacker can control (indeed, the attacker could control all parties other than the bank under this notion of security). The definition is slightly weakened for systems that support secure offline transactions: (loosely) if and only if more money is deposited than is withdrawn, the bank will be able to identify the parties involved in the attack and can prove that those parties acted maliciously (in a way that can be verified by all other parties).
In the case of Bitcoin, you cannot make any statements about deposits or withdrawals if you try to define security. It is also unclear how one might define security, since there is nothing wrong with a party that spends more money than it receives (due to the mining protocol). At best we can only speak in vague terms and vague notions of what should happen in Bitcoin versus what should not happen with Bitcoin.
"Bitcoin is the first ecash system that is truly decentralized."
That is debatable. On paper, Bitcoin appears to be decentralized, but on paper Bitcoin scales extremely poorly. To make Bitcoin scale well, someone occasionally declare a particular branch of the block chain to be the block chain, and all the users must accept this judgment. That is basically what happens now; the Bitcoin developers ship a client with this snapshot state included.
If you doubt the power that the Bitcoin developers have over the network in practice, consider the block chain fork a few months ago. That fork was triggered by an update to the "official" Bitcoin client (worse, it was not even caused by a "snapshot;" it was caused by a seemingly harmless deviation from how the previous client worked). In practice the Bitcoin developers could trigger another fork at any time, and could potentially profit by it.
"This is what makes it technically superior to prior systems"
Except for all the technical deficiencies. Even if we take as an article of faith the fact that Bitcoin is fully decentralized, even if we ignore the complete lack of a security definition, Bitcoin has technical deficiencies compared to academic systems. No support for secure offline transactions limits Bitcoin's usefulness in real-world applications. Enormous amounts of computation are needed to keep Bitcoin running, vastly more than are needed in academic digital cash systems. Academic systems have rigorous anonymity guarantees (except for "cheating" users); Bitcoin has no such guarantee and requires someone to operate a "mixing service" to provide some kind of anonymity.