The problems by the OP were known for quite some time. I'll add what I see as worrisome:
Manipulators taking advantage of a particular situation (MtGox) to crash the price well below the
'normal' drop for this stage of the market. This can be repeated on other exchanges.
I believe that there should be some kind of rules regarding exchanges, when their price falls below
50% of others', they should stop trading until their issues are solved (or not).

TERA has more trading experience than many other posters here, don't insult him.
What will happen will be just MtGox price rising close to Bitstamp price, with some volatility.
There will be no new ATH until the current bubble deflates, a new one starts and eventually grows exponentially.

Let's see how this turned out...
There was some despair, and I expected despair only during the last stage of wave C. Forgive me KARHU, for I have sinned! 
I wasn't bearish enough. What happened on MtGox was close enough to a market collapse. And greed turned into irrational fear.
For MtGox, this was the worst crash in Bitcoin history (large price drop during one sub-wave), worse than the 2011 drop from 31$ to 10$.
From 1093$ to 220$, that's an almost 80% drop. Absolutely crazy... 'Normal' behavior for MtGox after such a crash is a strong rebound,
but it seems the market is waiting for more than a neutral press release to regain some confidence.

FTFY! 

Because of the tighter withdrawal limits.

The news is mildly bullish for the other exchanges, with BTC withdrawals capped to an unknown limit,
there will be no crash on Bitstamp or BTC-E when people will cash out there.
In the meantime Gox may be arbitraging to make some $, because that's what they may be short of.
Not BTC, as the market seems to have believed, and irrationally panic sold.

efarah, your post is a good contrarian indicator.
Just 2 weeks ago there were over 30 million $ on the bid sum. Now it's below 5 million, but not much has left MtGox.
After the panic subsides, most of that fiat will be back, buying cheap bitcoins.

They should have already done that when the goxBTC price fell below 50% of stampBTC price.
But maybe they don't give a shit...

Of course they couldn't have lost so many coins, but their PR sucks. Instead of keeping mum, they should have come forward and admit that
a certain amount of coins was scammed from them, probably a 4 digit BTC sum. Bad management such as this can wipe out what reputation was left.

The drop from the unsustainable 950$ level was unavoidable. But the normal large correction, which should have been in the same ballpark
as the December drop to 455$ (or a bit higher) was much worsened by the suspended BTC withdrawals. On top of that, the last drop,
down to 220$, seems to have been manipulated. 1h MACD was going positive, but the sudden dumps following a spike to 540$, are abnormal IMO.
It's possible someone took advantage of the irrational fear in the market and shorted goxBTC hard.

It is in MtGox's best interest to end the panic asap. Their fiat fees took a plunge too.
But Karpeles is too slow / incompetent to understand this.

Manipulating whales already ate the fish who panic sold so low. If BTC withdrawals resume, my guess is
we'll see the bid sum jump by about 5x and price about 3x. Similar to the rebound of the 12th April 2013.

It seems MtGox has started BTC withdrawals, but the transfer queue has been flooded with requests.

Once the BTC withdrawals on MtGox will resume tomorrow (the official statement), price on MtGox will quickly jump to
the level of Bitstamp or even a bit above. After that, it's anybody's guess...

I voted manipulator. Before the dumps there was a spike from 380$ to 540$, probably
the manipulator bought his own coins, and then sold them to create downward momentum.
MtGox should have stopped the trading after seeing this unnatural market movement,
and then resume trading only after withdrawals would resume.

The BTC withdrawal on MTGox has switched to this message:

Identification required to access private API

Does this mean that the withdrawals work, but only for internal testing by developers?

"
Dear Mt. Gox Customers,
"
"
In order to implement our solution to the “transaction malleability” issue being
faced by bitcoin exchanges and businesses, we are going to have a 6-hour
downtime on all bitcoin deposits and internal bitcoin transfers in addition to the
current pause on bitcoin withdrawals. Trading will otherwise still be open as
usual.
"
"
Maintenance Schedule (approximate):
"
"
6pm ~ 12am JST (February 15
th
)
"
"
The above downtime period is approximate: it may be shortened or lengthened
as required. Once the implementation is complete customers will again be able
to deposit bitcoin, but we will be doing extensive testing before bitcoin
withdrawals are reactivated. We will publish an update on the situation on
Monday .
"
"
BlockChain.info have implemented changes to address the malleability issue.
Our solution should work in the short term, while a longer-term solution is being
discussed with the Bitcoin Core Dev team and the Bitcoin Foundation. We are
also discussing this with other exchanges and businesses.
"
"
Thank you for your support during the maintenance, and we will update you on
the progress shortly.
"
"
Best regards,
"
"
MtGox Team

For me the question is: those hackers that the OP was somehow close to, have they finished their attack?
They expected to take the price down to 100$, and even on MtGox it's looking very unlikely to happen (happened on BTC-E though).
Do they have another ace in their sleeve, besides the malleability vulnerability? And if so, will they deploy it
today or tomorrow, after the exchanges allow BTC withdrawals, to spook and crash the market again?

MagicalTux:

This is getting us nowhere. There is indeed so many things we could do on our own even at MtGox, however this merge request's purpose is to define a standard others using Bitcoin can agree to and that can be implemented.
Getting rid of malleability would be the ideal idea, but this won't happen anytime soon no matter how everyone tries. It can be made harder, but not impossible.

On the other hand, I believe keeping track of what is actually signed when a transaction is issued makes sense, and it seems that some others here agree to that.

Re-issuing of transactions should be done using the same inputs, but as of today this poses a problem as said txs won't be relayed as easily as clean txs. There is also the fact that people using regular bitcoind as backend won't be able to do that either.

Keeping only a service-specific ID stored in the transaction is not a solution either, as it would be difficult to index globally (ie. we have to find the right txs from the whole blockchain).

Anyway we came up with this new hash solution because:

    it requires no change to the protocol and will not cause any forks or issue to people not using it
    because bitcoind already has facilities to exclude the txin script from a tx to hash it, it is very easy to implement
    because it's a hash of what is actually signed, anything causing this hash to change would also invalidate the signature

As for CoinJoin, I believe the client will have a view of the transaction before it is actually sent (to ensure it includes its outputs and to sign it). As such it is perfectly possible to fetch this hash at that stage, even before knowing the actual tx hash (and it could remove the need for the client to see the actual tx to know its hash as they potentially wouldn't need it anymore)

more MagicalTux:

Just to update this thread, it seems that this discussion is mostly stale now. We (at MtGox) will implement this new hash index in our transactions database and start working with it (we will announce a maintenance as we will have to stop bitcoin deposits too during the database schema update) and will start providing this new hash when customers are withdrawing bitcoins, litecoins, or any other coin based on Bitcoin we may support in the future.

We will also provide an API that will allow our customers to use this hash to retrieve the transaction hash as seen in the blockchain once the transaction is confirmed, and will hope others (blockchain.info?) will index this value one day.

We also invite other exchanges and businesses which may need to keep track of bitcoins they send to use this same method, since dealing with multiple variations of the same thing wouldn't be very productive.

If nobody does it, we will also post some test vectors for regular (in=>out) transactions in the near future.

a comment by gmaxwell:

Reissuing a transaction without reusing the inputs is unsafe. You cannot do this and be confident you will not be robbed, because there is nothing preventing both transactions from going through. No amount of checking can provide protection in that case, because the prior transaction may not have gone through yet but still may go through for as long as it has not been conflicted— or even after it has been, if the conflict can be removed in a reorg. It may be slow, it may not work super well, but it is the only way to prevent transactions from being paid twice. This has nothing to do with malleability: You simply cannot pay someone twice and not risk them actually getting paid twice, unless their original payment is impossible or the transactions are mutually exclusive.

If including this patch is going to make even one service believe they can safely reissue in this manner than we must not do it.

Pull requests here are not used to define standards, normally "standards"— in so far as we have them at all in the Bitcoin community— are defined using BIPs. The GitHub page was a quick way to get code up so that people could start commenting on it— and get it if they needed something to use internally to help sort things out.

It is not our responsibility to run your service, so if you're waiting on anything on this pull req you are doing something wrong. You already issue several kinds of mtgox proprietary ID with your transactions.

    anything causing this hash to change would also invalidate the signature

This isn't true for all transactions, it's true for the conventional ones you issue— indeed. Some transaction types are inherently malleable and no ID can be both unique and non-malleable for them.

    Keeping only a service-specific ID stored in the transaction is not a solution either, as it would be difficult to index globally

I am not a fan of putting an extra ID in transactions because it bloats them, it's bad for privacy, and can potentially be simulated in other transactions (unless you go through the heroic effort of making it a signature)... But there is no reason why it should be any more difficult to index than any other data from a transaction. Instead of running the normalized ID extraction, you run the service ID extraction, and index that if there is one.

The price is going down because of inertia. Once a large drop starts, it needs a strong upward trend to break it.