I should mention a technical issue here. If we have an upgrade that changes the note plaintext format and does not include ZSAs, I believe that the new format for Orchard (with lead-byte \mathtt{0x03}) should nevertheless include the \mathsf{asset\_base} field. This would be required to be the constant 32-byte value \mathsf{LEBS2OSP}_{\ell_{\mathbb{P}}}(\mathsf{repr}_{\mathbb{P}}(\mathcal{V}^{\mathsf{Orchard}})) as long as ZSAs are not deployed — and it would be specified that any other value is reserved for a future deployment of ZSAs, not for any other purpose. The change from \mathsf{memo} to \mathsf{K^{memo}} would be applied iff memo bundles are deployed with this note plaintext format change.
The advantage would be that no further note plaintext format change would be needed to deploy ZSAs, which would simplify ecosystem compatibility with the ZSA deployment: wallets that do not support receiving ZSAs would automatically do the right thing for all outputs. This does not require any dependency on the ZSA specs, and so it has almost zero downside apart from front-loading a 32-byte increase in the note ciphertext size for an Orchard output.
Whether to do this is a technical protocol design decision and does not need to be voted on. The reason to mention it here is that it makes “deploy memo bundles + quantum recoverability in NU7, then ZSAs in NU8” a more feasible path. (I know @nuttycom was interested in this approach; I’m undecided but absolutely do want ZSAs to be deployed.)
[Edit: this idea is filed as Include AssetBase in the note plaintext · Issue #1217 · zcash/zips · GitHub .]