I use a two-fold strategy. I am not using AudioProcessorValueTreeState, but my own ValueTree based state system, but the same principles could be applied.
Most importantly I save two version numbers with each patch. One is the current version of the plugin and the other the minimum compatible version (for forward compatiblity).
When a patch is loaded I compare these values to the current plugin version.
- If a patch of an older version is loaded I run the data through a routine that might adjust some values which definitions might have changed over the lifetime of the plugin. If the data to load comes from a future version I check the min compatible version and refuse to load in case it is too new to load. Ideally this never happens.
- When the plugin is first instantiated, default data is created which contains all parameters of the current version. I store a copy of this initial state data (before any preset is loaded) in memory. It can be static as it the same for all instances. Every time a new patch is loaded I first load this initial data again and then load the patch. This makes sure that any parameter that has been added in later version gets its init value - even if it isn’t preset in the older data to load.
Not sure these are standard approaches, but they have worked fine for me with plugins that have added lots of new patch parameters and changed some definitions over their lifetime.