CSR1000V on ESX: I keep getting bitten by vApp Options

I use a CSR1000V on ESX in rare occasions and have found (3 times now, because I keep forgetting) that my workflow is unsafe.

Generally speaking, that workflow looks like:

• Grab the "for VMware" OVA bundle from Cisco.com
• Attempt to deploy the OVA
• Become enraged that the OVA includes an unrecognized interface type
• Unwrap the OVA, fix the OVF within, fix the checksums, roll it back up
• Deploy the fixed OVA, ignoring all of the pre-deploy configuration capabilities (I understand there's cool automation potential here, but I generally need just one or two routers for a quick task, this is not a automate-the-fleet situation)
• Enable IP/SSH/AAA via the VMware console
• Finish the job in the usual way over ssh

At this point, everything's fine, the configuration is saved, the router reloads, the configuration is getting vacuumed up by RANCID, etc...

Then weeks later, when there's a problem with the hypervisor (crash, power failure, etc...) I discover the "flash" and "nvram" of the virtual router have been wiped clean by the vApp Options checkbox.

The deployment guide mentions vApp Options, but only as a feature, not as the hazard that I've found it to be.

Am I doing something obviously wrong/stupid here?

Have the rest of you been through this?

Why have I been encountering the bogus interface type error for years, but the internet is virtually silent about it?

I'd like to improve my workflow, but it's not obvious to me where I've gone off the rails. I suspect it's early in the process because of the OVA incompatibility.

Remembering to uncheck the box is a strategy I can try to employ, but I'm guessing the problem runs deeper than that :)