The failure mode I ran into is that I tore down an a4x2 deployment, then started a new one that I expected to be a clean slate, but at least on g0 it had all of the state from the previous run's internal zpools. I don't know for sure what happened. But I normally set FALCON_DATASET when using a4x2 and I suspect that I neglected to set FALCON_DATASET for this invocation of a4x2 destroy and it tried to destroy the wrong datasets. It would be nice the tool recorded the locations of these datasets (like it does a lot of the other configuration) rather than relying on the user to consistently set it each time the command is run.
I'm not sure if this is also the cause of #67.