>The data in the memo field is not readable as it is stored encrypted, but the RESTORE command will restore all the stored variables.

Not really encrypted, just binary. You can actually access those binaries and even extract variable names from the file or memo by simple string manipulation (which I did do once, to check the length of arrays and few other things before restoring).

The bigger problem here is that Save/Restore is about 1.8 light years behind everything else in VFP.

First, it saves any visible variable without preserving its scope. It saves global, private, local.
Second I'm not sure whether it saves objects, most probably not.
Third, when it restores, they all become private to the code in which they were restored, which is bound to create very interesting bugs. Well, maybe not private - haven't done this for a dozen years, maybe this was fixed, but I have serious doubts here. Anyway, between the location where variables are saved and the location where they may have been restored there's bound to be some difference in the content of variables, and as these variables define the context, the context at the moment of restoring would revert to the context at the moment of saving, most probably confusing the hell out of the code. The only way I see around this is to save only some variables, those that keep the state of what we want to save - which can be done by prefixing these variables, and doing a Save All Like myprefix*.

If Mark's idea was to dump variables into a text file of some sort just for debugging purposes, then List Status is the way. Save/Restore is just plain dirty IMO, and very risky. It may have unexpected effects.