They didn't fix malleability, it is still possible for transactions to be modified.
They reduced the odds of modified transactions being accepted into the block chain.
Most of the changes in 0.9 related to malleability, and 100% of the changes in responses to the attacksattacks, were changes to the wallet behavior. The wallet will not become confused now if change is mutated. There is now a switch to disable spending unconfirmed change, but by default it still does. But, for example, it will notice as soon as change is conflicted in the chain and not try to spend it, greatly decreasing the potential disruption.
(0.9 also included the fix from last September that expanded the definition of non-canoical, but thats not really important to changing the behavior here)
could prove catastrophic for any business that allows it.
Thats pure hyperbole. The worst case consequence there was that you get transactions stuck which require technical intervention to unstick in your wallet. An annoying DOS attack but hardly "catastrophic to business".
It is a bit weird that nobody has replied to this very critical question, could somebody please shed some light on this one?
It's not weird, you asked in the wrong subform and no one who cared to answer it noticed. This should have been posted in technical support.
If you'd prefer transactions to fail when you run out of confirmed inputs instead of creating a risk of getting stuck you should set spendzeroconfchange=0 in your configuration.
