Why Scanstate and Loadstate require a top level directory path to a migration store

If you have played around with USMT a bit you may have noticed that both Scanstate and Loadstate require that StorePath (the path provided on the command line to where you'd like the migration store placed) be simply a path.  However, when creating a compressed migration store (the default behavior) Scanstate places the .mig migration store in a subdirectory of StorePath.  For example, if run the following command:

Scanstate c:\test_store [... lots of other switches]

When complete, my directory structure will be as follows:

Directory of C:\test_store\USMT3

03:19 PM <DIR> .
03:19 PM <DIR> ..
03:20 PM 7,833,045 USMT3.MIG
1 File(s) 7,833,045 bytes
2 Dir(s) 

More curiously, Loadstate also expects that StorePath be simply a path to a top level directory -- in fact the same path that was provided to Scanstate.  So, in the above example, my Loadstate command line will need to look like:

Loadstate c:\test_store [... lots of other switches]

It can't look like:

Loadstate c:\test_store\USMT3\USMT3.MIG [... lots of other switches]

(this will produce an error regarding StorePath being invalid)

Why doesn't Scanstate or Loadstate allow you skip this forced directory hierarchy and directly handle the .mig file?  The reason is simple but subtle.  As discussed in a previous post, USMT allows two different kinds of migration stores.  The first is the compressed migration store covered above, and the second is the uncompressed migration store.  Lets come back to this question after we look at the directory structure of an uncompressed migration store.  If we run the following command:

Scanstate c:\test_store_unc /nocompress [... lots of other switches]

We get something like this:

Directory of C:\test_store_unc\USMT3

03:46 PM <DIR> .
03:46 PM <DIR> ..
03:44 PM 36,357,347 catalog.mig
03:44 PM 2,156,848 MIGSTATE.DAT
03:46 PM 0 status.~lg
3 File(s) 38,514,195 bytes
2 Dir(s) 

By requiring that StorePath be the top level directory we can essentially abstract away the need to specify different paths to different file formats for our different migration store formats.  As we can see above, regardless of whether or not I have created a .mig file or both a .dat and .mig file, all I need to know is the top level directory.