Are there also safety measures in case the initial release of the code is ok and approved, but malicious code is integrated through upgrades?.
All upgrades should be audited as well. However, the audit to determine whether a chain has malicious slashing code in it is a lot easier to do than the audit to determine if it itself is secure agains attackers. But in general, the overhead of this auditing of all upgrades is a big reason we are trying to move towards an untrusted consumer chain paradigm as soon as possible.
One interesting thought is that being removed from the active set is already quite a punishment, even without having a x% of delegations slashed. Because that effectively puts your commission at risk and your reputation. So a simple but effective measure might be to make the period longer after which you can re-enter the active set. That way you already have a simple but effective trigger to make sure your uptime is ok.
Jailing already is effectively the main punishment for downtime, not the slashing. This is why we were able to remove the slashing component for greater safety while still disincentivizing downtime.
How will this work when it happens on multiple chains at once? Will that means that we will get a long queue of waiting slashings, which will take a long time to clear?
Yes, the throttle has one queue for slashings from all consumer chains. What it effectively does is prevent jailings from consumer chains from changing the power balance on the hub radically in a short time, since this is the scenario we are trying to prevent.
Under normal circumstances, the throttle will have very little effect on day to day jailings. Sometimes if several large validators have downtime at the same time, one of them will have to wait an hour before being jailed.