A data broadcast doesn't have to be 100%. If the broadcast gets the user 95% of the data then he cuts his bandwidth requirements over his conventional link by 95%.
That's my point. It might be good for 95% of the data. But, you need bi-directional communications to get 100%. Prior posters are envisioning a lite client that solely relied upon the broadcast. The lite client does not need 100% of the block chain. But, it does need 100% of the block chain that is relevant to it.
The client knows when it's missing a block,
The client WILL miss a block at some point in time, for whatever reason. That is a certainty. The Client WILL miss a rebroadcast(s) eventually too. But, the client does not know if the missed blocks are relevant to it. At a minimum, it needs bi-directional communications to requested the missed blocks. More likely, to reduce bandwidth on a slow/expensive connection, it queries the block chain for transactions with it's addresses, and if the blocks are not it its storage, then request those blocks to be transmitted either via the slow/expensive connection, or through the public broadcast.
One possible minimum slow/expensive communication is to send to the public broadcast a request with: Addresses, and Last Good Block Number (last block number where it knows it has 100% of the relevant blocks). The public broadcast could then rebroadcast any missed blocks.