Hi, Robin-

I'm glad that was useful, and thanks for clarifying some of the original message.

Just as a nomenclature point, the "T1" in the SUMA/ directory is the one with "SurfVol" in the name, yes? We usually refer to that as the "SurfVol dataset" (for guessable etymology). It does have the same grid as the output ROIs (aparc*nii*, *REN*, wm*seg*, etc.). NB: I just processed a "T1w orig" that had obliquity, and none of the NIFTI datasets in the output SUMA/ directory come out with obliquity. So, if your input dataset is oblique, it will not directly overlay on these outputs---I think you could use @SUMA_AlignToExperiment to align the SUMA/ directory sets to the input. But if you deoblique your data before putting it into recon-all, then the data will overlay fine in the AFNI GUI (though, likely the grids will be different, because FreeSurfer makes the 1mm isotropic voxels in a 256x256x256 matrix datasets).

Re. "1) Normal recon-all case"
Yes, if you deoblique your original dataset, then "-deoblique_refitly" should not be doing anything, because there is no obliquity to apply.
One small thing I just noticed will happen by default with keeping "-deoblique_refitly" is that the deobliqued dataset will have RAI data orientation by default. It won't *move* at all spatially (at least not in AFNI), but I had not noticed this before. I might add something to change that within @SSwarper.
But in general, removing obliquity while "keeping the coordinate origin", with this does:

3dcopy sub109-1_sT1W_3D.nii tmp
3drefit -oblique_recenter tmp+orig
3drefit -deoblique tmp+orig 
3dcopy tmp+orig sub109-1_sT1W_3D_do.nii

... seems to me to be preferable than applying the obliquity with "-deoblique_refitly"---if there *is* obliquity in the dataset, then it would be regridded (=blurred a bit) by applying the obliquity. Why have unnecessary blurring? And why not make it easier for outputs to match inputs? So, I would do the above deobliquing-while-keeping-coordinate-origin at the start, and not do include "-deoblique_refitly" in @SSwarper.

Re. the longitudinal aspect---I am afraid I don't know. I don't have a good set of data to test this. If I were approaching this, I would deoblique both input anatomicals (probably preserving the coordinate origin, as described before) to remove that possible hassle. At the end of it all, it strikes me the final data should overlay either the first "T1w orig", the second "T1w orig", or, if the program is generating some intermediate "template", then that space. It is hard for me to see how the datasets could not overlay one of these three possibilities (assuming the issue is not due to obliquity in the input).

I would be curious if you could upload a pair of datasets and I could use your commands to see what happens; however, I will be out for a couple weeks shortly, and I am afraid I won't have time to run everything before heading out.

--pt