Simplifying the light wallet protocol so that it’s easier to implement and can fit into more places should also be a primary consideration, alongside performance. A zcash light wallet is pretty complicated in terms of code size and in its need to maintain local state. The complexity and the need to scan makes Zcash not-so-competitive against things like the PayPal API, where state is mostly stored server-side and clients just make API queries to access it.
That complexity may be holding Zcash back. Compare the cost to implement a light wallet SDK in JavaScript of $300,000 (which is not unreasonable) to the day or two of work it would take to get started with PayPal by using standard HTTP requests to their API. We need to move closer to the latter, if that’s at all possible.
We also need to consider that the true cost of each major change to the core protocol is some multiple larger than the cost of making that change itself, because everything that supports Zcash needs to be updated to support the changes. That multiplier will grow as more projects integrate Zcash. If the status quo is fine for now, perhaps that’s an argument for avoiding incremental improvements and making a bigger leap to something much better (I’m not sure).
I’m imagining a future overhaul of the protocol where wallet-to-wallet messaging eliminates scanning so that all a wallet has to do is receive its messages and update its state, which it stores as an encrypted blob on the light wallet server. How close can we get in terms of UX to something like the PayPal API, with a library that only needs minimal cryptography, while still having great privacy?
There could always be another sandblasting attack, and I want Zcash to be adopted to the point where blocks are full, so I don’t think detection keys should be dismissed, but these are some more things to consider.