Well, the crash of mapsin1 maybe caused by gdbm routine which keeps allocates/release memory(in number of 10s of thousands of times), or fetch a corrupted tile, Windows runtime is notorious weak in doing that. But it won't damage your map files. Just keep running it, the saved map files will be skipped.

I like to explain the new format in the more detailed fashion here. In MM1.4, the map file is stored in z, x, y as the path name, one file contains 1 tile. It doesn't have a centralized data table, which is very good for a SD card storage system. It's fast, scalable, spreaded writing in the whole SD card. But the drawback is the waste disk space, since each file only contains 1 tile.

I personally won't use GDBM file system on a SD card, which may damage or kill the card, with the only benefit of small storage space. That file system was designed 15 years ago and has no idea about flash storage system. It maintains the centralized storage table, the hash table(bucket). The MM2.x updates(sync) that table on per tile base, which means on a 32k allocation unit card, it writes about 3000 times to fill a table block(bucket). A SD card block has the limit on times of writing, and that makes the block very easy to be damaged permanently.

The new format inherites the MM1.4 file system idea, it uses z, x/4, y/2 as the file path name, thus each file stores 4x2 contiguous tiles. It doesn't have a centralized data table as well(which you should always avoid on a flash card), and provides the balance between speed and storage space, and no potential damage to your card.

Some thoughts:

Since the new format store 4x2 tiles, each file stores 2 tiles in y direction(4 in x, the way of this was designed considering tablet's screen resolution). It may not work ideally to store maps along road in North-South direction, in scattered manner, like California costal area. In this case, you should use small allocation unit. Actually I don't think small allocation unit under the new format will bring much penalty in access speed, because the new file system always tries to read/write the 8 map tiles together. It greatly reduces the read/write times on your SD card, thus extends its lifespan.

I am considering to use 3x3, 4x3, or 4x4 tiles per file as the more balanced storage format. Anything beyond that is not necessary and may bring acess speed penalty. This is basically an engineering experiment on MM. It's clear that we can find ways to improve it dramatically.