What happens to transactions in the mempool when their parent transaction expires?
Yes, this is an accurate description of the mempool behaviour. When a transaction is expired from the mempool, its descendants are as well.
When txA gets dropped, so does txB. If we later re-broadcast txB (and it's not too large) our peers will add it to a (small) cache of orphaned transaction they keep for us. If we broadcast txA in the next 20 minutes (timeout for orphan tx cache eviction), and it passes policy checks on its own txA would be added back to the mempool.
Note that the peers would only request it if we send them an inv for txA.
However, there are no such thing as &quot;propagation as a unit&quot; on the P2P network currently (package relay design is being discussed here). This is the reason why in your example txA must pass the policy checks on its own.
This has implications on L2 protocols with pre-signed transactions, for example in the Lightning Network where the transaction relay is critical. A pre-signed txA which happens to be below most of the network mempool minimum feerate at the time of broadcast won't be accepted even with a high fee-paying txB (1)(2).

(1) This is the reason why the Lightning protocol kept the update_fee message even post anchor outputs.
(2) This has implication in other L2 protocols too. For example in Revault it could prevent one to unvault a vault until the mempool backlog is processed.