SPV clients are very useful for wallets that dont want the entire blockchain locally, however as the blockchains grow in length, the number of headers required grows linearly. With equihash coins, the header size is 2kb, so this effect becomes quite a large overhead, ie. 2GB per million blocks. Just for the headers!
If we are willing to use the notarizations as a verified blockhash, we can reduce the number of headers required to just the headers that are in the blocks near the utxo in a specific wallet. As little as 10 headers would be needed to get full confirmation on a specific utxo.
Remember that on average, there is a notarization every 10 blocks and each notarization has the height and blockhash. Given a specific utxo, on average 5 blocks prior has a notarization and given the headers for the next blocks until the next notarization will allow to confirm that the headers are indeed valid.
Given a valid set of headers, a txproof that validates to the merkleroot in a specific block, will prove that the txid was indeed mined into that block. The raw tx bytes will hash to the txid.
Given N utxos, the total headers needed would be at most N times as much headers, but in many cases, the same headers will participate in proving the validity of more than one utxo.
In order to allow a very efficient way of creating the minimal data set required to prove a set of utxo, rpc calls can be created to find the nearest notarizations to all of the utxo. This combined with the usual merkle txproof will enable orders of magnitude less headers to be required to prove all utxo in a wallet. In a blockchain with a million blocks, validating a single utxo would require a million headers, vs. an estimated 10 headers. Of course, with N utxo, the nSPV is bounded by the estimate of 10*N headers, while the normal approach is the same million headers. but even with 1000 utxos, that is estimated 10000 headers and 100x more efficient.
On the issue of non-notarized blocks for the most recent transactions, a node could monitor the network for the incoming blocks and transactions, to get a realtime status of each non-notarized transaction. For small amounts this is more than sufficient, but for larger amounts, waiting until the next notarization comes in will be recommended.
nSPV clients thus are a way to leverage existing notarizations to gain 100x to 10000x reduction in headers (bandwidth and storage) needed to validate a set of utxos in a wallet. The tradeoff is relying on the notarized chain, so if that tradeoff is acceptable, this creates a way to implement the next generation superlight nSPV wallets.