A few additional details on the above:
For #6, the "fixed" 31 tile padding is only on the left. The right side has a variable amount of padding. Basically, it doubles the size of the map, and shifts it right 31 tiles. All the rest of the doubling is extra padding on the right, so it's usually more than 31 tiles. Also, the 31 tiles I don't believe is fixed. I think that may have something to do with the clip rect in the .map files, or a similar field that can be changed. (Not that it ever is, or that I'd recommend changing it). I believe the reason for doing this, was to provide some padding map area for when the AI units drive off the map. It might also be used to have units drive on the map. I guess it was a way to avoid special casing the movability of those tiles.
For #5, blight and lava spread speed does vary according to the size of the map, but in a slightly odd way. What it does, is it sets a number of tiles to randomly check for expansion. This number of random tiles is scaled according to the map size, but it's done in such a way that a map with 2x as many tiles will check 2x as many tiles for blight expansion. Really, this seems more like a way of evening out some spread speed setting, so that it spreads at roughly the same speed on different sized maps. If this scaling was not done, then a map with 2x as many tiles would have about 1/2 the chance of randomly picking a tile already next to some blight and thus expanding it. Mind you, this probability argument isn't perfect as the probability will vary according to the size and shape of the blight. This random checking results in the tendril like growth of the blight, where of course the probability of a long tendril is pretty small, as is the probability of not having anything tendril like. Of course, you might choose to implement this differently, where the blight has some sort of edge tile list. That would probably allow for faster expansion code, but at the cost of more memory. I imagine the random expansion was done the way it was to conserve memory.
For #4, the variant isn't normally quite so clear cut, and the bar yield need not be either (although it is). Sometimes there are variants that just seem plain better than others. For instance, there is a 1 bar variant with initial, peak, and long term yields of: 100, 250, 150, comparing with another 1 bar variant with: 100, 200, 100. If you check mines.txt from sheets.vol, you'll see that for each bar yield, there is a variant with higher long term yield than the other two. Note that they all happen to start out at the same value for a given bar yield. Also, the transition from initial to peak, to long term yields for each variant takes a different number of truck loads. If you were to graph the yields, some variants would have a higher but narrower peak than others, or would have different rise/falloff rates on either side of the peak. Of course the peak values are somewhat insignificant as the transition period is between 10 to 60 trucks on either side of the peak value, and the difference in peak values is at most 50 ore per truck load. The widest peak is 80 truck loads from base to base, which would give about 80*50/2 = 2000 extra ore above the long term rate. (Divide by 2, since they are sloped, so you basically have the area of two triangles instead of a rectangle). That buys you about 2 lynx. If you have a variant with a higher long run yield, such as the 1 bar mine, that's a difference of 50% over the long run. Much more significant overall.
In fact, if I was ever going to cheat by making a map so that I "randomly" got better mines than other people, that's how I'd do it. I'd force the mines in my vicinity to be of a better variant. There is no way to visually tell in game. You'd need to mem hack to find the variant type, or be watching the peak and long run values to figure it out. Of course, part of the fun of having variants on each bar yield is not knowing ahead of time the exact amount of ore in the mine.
