SPV mode stores only the most recent block headers. When a user uses the light wallet for the first time, the light wallet will sync with the Bitcoin nodes from a staring point of block header.
The getblockhash message contains only one uint32_t field that means block height to indicate the needed block.
bitcoinj and other SPV clients infer the starting block using the fast catch-up timestamp concept, that is typically the timestamp of the oldest key in the wallet or -in other words- the timestamp before which we know no relevant transactions exist. The FCU is totally blockchain agnostic so there should be a way to translate the timestamp to an effective checkpoint block instead. Using a block height instead of a hash is of no help to me, we don't know in advance which height to start at anyway.
In this BIP, I want to improve the way to find the first block header we are going to store in the client. What you are saying is since which block we may want the transactions in it. In another word, I'm talking about which block to start header downloading. While you are talking about which block to start body downloading, which means header downloading should end in the mean time. We are not talking about the same problem here.