You're not listening. MtGox built their own subway with flawed doors. Only MtGox can fix those doors.

They fucked up by assuming that if the txid they sent didn't make it into a block, then no other txid could have spent those coins so they didn't bother checking the blockchain to make sure that was the case.

Transactions have always been malleable prior to being included in a block. This wasn't really apparent until 2011.

I'm proposing one small change to Bitcoin's JSON-RPC api:  return a transaction ID when Bitcoins are successfully sent.

Why?  Because I want to keep a complete audit trail for any coins going into or coming out of my application's wallet; I want to keep track of the particular transactions in the bitcoin network that correspond to actions my application takes.  The alternative is to call sendtoaddress and then call listtransactions, but that won't work properly if two similar transactions (same amount to same address) occur at about the same time.

In 2010.  If I recall correctly 2010 is before 2011.

This address too: 1SochiWwFFySPjQoi2biVftXn8NRPCSQC

italian, swedish or texan people will probably beat the japanese to it.
You know MtGox is not a japanese company, right?

The problem is not "why is it not done yet", but more "why is it more urgent than taking care of bitcoin's ability to handle much larger transaction volume"?

Because it wasn't considered to be high priority problem.

I hate to be the devil's advocate here (especially being a newbie), but how does "known about since 2011" fit with "cannot be corrected overnight"?

Nights are extremely long on Mt. GOXXX.  They don't experience Linear Time as we do, down here on Earth.

Also there is no concept of ownership.  "Your Coins" are "Our Coins".

I hate to be the devil's advocate here (especially being a newbie), but how does "known about since 2011" fit with "cannot be corrected overnight"?

The issues that Mt. Gox has been experiencing are due to an unfortunate interaction between Mt. Gox’s implementation of their highly customized wallet software, their customer support procedures, and their unpreparedness for transaction malleability, a technical detail that allows changes to the way transactions are identified.

Transaction malleability has been known about since 2011. In simplest of terms, it is a small window where transaction ID’s can be “renamed” before being confirmed in the blockchain. This is something that cannot be corrected overnight. Therefore, any company dealing with Bitcoin transactions and have coded their own wallet software should responsibly prepare for this possibility and include in their software a way to validate transaction ID’s. Otherwise, it can result in Bitcoin loss and headache for everyone involved.

The Bitcoin core development team has worked to limit transaction malleability. There is broad agreement in the community that this needs to be eliminated. Finding the best and most responsible solution will take time. In the meantime, users of the reference implementation do not need to be concerned. Transactions are always tracked properly by the Bitcoin-Qt/bitcoind software.

This is a good reminder that Bitcoin is still young and experimental. There are best practices to think about and account for by those who want to build companies. To help improve both the reference implementation and third party software, the Foundation is committed to working with companies to produce best practices to help improve software.