Order of Exchanging Revocation Keys during Lightning Transactions How do Alice and Bob share their ephemeral private keys simultaneously? If they don't, and let's say Alice first sends Bob her private key. At this point, Bob can broadcast his current commitment transaction, and the previous commitment transaction (as he still has not sent his previous commitment transaction's private key to Alice yet). But Alice can only broadcast her current commitment transaction, as she has sent her revocation private key of her previous commitment transaction to Bob already. This asymmetry is a bit baffling.

If the previous commitment transaction favored Bob, what prevents him from broadcasting it - knowing that Alice cannot penalize him.

My guess of an answer for this is that they share their private keys based on whether value is flowing from Alice to Bob or Bob to Alice. As in, if the previous commitment transaction favors Bob, then he has to share his private key first. Or some such.
Alice and Bob jointly create a public key R for each revocable output (RSMC output script).

They each privately generate r-1 and r-2, and derive public keys R-1 and R-2 from these. R is the sum of R-1 and R-2. No secrets have been exchanges, only public keys. So R is unspendable by either. However, it is spendable by r = r-1 + r-2

When a new commitment tx is created, this RSMC must be revoked. If the new tx commitment favors Bob, then Alice must share r-1 with Bob. Now bob knows that he can spend this revoked output if Alice broadcasts it. Bob doesnt need to share r-2 with Alice as he would rather broadcast the subsequent tx favoring him.

Pre-images are used for routing (htlc output scripts) See later slides in chapter: https://teachbitcoin.github.io/payment_channels.html#/