[okay, let's try to post this again...]

As far as I can tell, the NIFTI files that AFNI creates do contain slice timing info within the AFNI extension fields, but it is apparently ignored when the NIFTI file is read. For example, the slice time offsets don't show up in 3dinfo, 3dTshift gives an error message because it thinks the dataset is already aligned, and the offsets get discarded entirely when you use 3dcalc to convert the NIFTI file to a BRIK. It seems some functionality is missing in the NIFTI reader library code in AFNI.

Currently, I think only 3dTshift, "3dvolreg -tshift", and 3dretroicor use slice times. Until they have figured out how to read slice times in AFNI NIFTI files, you will have to create AFNI BRIK/HEAD files with to3d and _leave_ them as AFNI BRIK/HEAD files to use these programs optimally (then convert them to NIFTI files after you are done using these three programs). Simply converting your NIFTI file to a BRIK file won't work because the slice time info will currently not be converted.

As for your second question, I believe Dimon does not actually detect slice order from DICOM files; it just happens to default to alt+z since that's a popular acquisition order (hence Dimon has an option to change this). I don't know where MRIcro is getting the slice order from, but it's apparently not reading the AFNI extension fields in the NIFTI header (no surprise there), which is where the correct info currently resides.

Fred