So each level has a region that would have to be selected before editing? Something like "this is a wood/desert/ice level"?

That wouldn't be that bad, imo.

I wish... Anyway, each region is 256 16x16 blocks. The raw 16x16 data is uncompressed and stored in a level-specific bank. The region data refers to this. For example, in the beginning level, the region (level assembling) data is something like this:
01 02 03 04 05 etc... As this is, I guess, to save space.

So, now for tileset indexes, I'll go in-depth and explain it. It seems when for every two regions changed, the tileset changes. The tileset index is already set before the loading code, and I can't seem to find what calls that (Probably because it most likely sets HL and resets the code and just jumps to whatever it is). However, since the tileset loading code is called BEFORE you switch a region in some cases (For example, in the beginning level, after the first cutscene at the truck, go right, and it'll be called when part of the truck is still there, and then again when it's gone with a new tileset), it makes me think it's triggered by some other data. I've found that during the level loading procedure (The level "header", I suppose), there's a code that makes the tileset index 02, but only for the first region. I think the second region might carry on from the first (First/second referring to the regions in groups of 2). It seems every tileset it loads is in groups of 2. Here's level 9 (The beginning level)'s region tileset indexes.

00 = 02
01 = 02
02 = 04
03 = 04
04 = 04/0E??
05 = 06
06 = 06
07 = 06

00 = 08
01 = 08
02 = 08
03 = 08
04 = 0A
05 = 0A
06 = 0A
07 = 0C
08 = 0C

The current region value in the memory seemed to reset after hitting the first 07, so that's why it's spaced.

The tileset index helps get the tileset pointer. For starts, it's "0xFC77A + (currentlevel * 2)". Calculate the pointer there, and you're up with another pointer. Calculate that pointer and add (tilesetindex * 2) to it. Read a byte, and if it's FF, you skip the next step (So I suppose..., and I guess you do something else, but I haven't bothered to figure that out yet). Set the "tilesetindex" value to the byte you just read. Go to 0xFC970 and add (currentlevel * 2) and finally (tileset index ^ 3). Calculate that pointer and you're at the tileset data. Note that this tileset data ONLY contains the 3-byte graphics pointer (And some other useless byte) and the palette/formation data is always the same depending on the level.

I know I did a bad job explaining, but it's hard to and I just woke up. If you're curious, the beginning level's (Its id is actually 09) bank is 0C. The block palette data is the first 0x400 bytes (0x100 bytes per corner, going from top left - top right - bottom left - bottom right). The block formation data is the next 0x400 bytes with the same format as the palette data. The next **** bytes are for collision data, but I haven't looked into that. Region 1's data starts at 0x30A60. The actual level assembling data (How the regions are arranged) is at 0x32000.

NOTE: I'm not 100% sure on everything, although I'm pretty sure it's all right since I've tested it in a level viewer I made. However, I am aware of the fact that I still need to find something with the region raw level data, as it starts to jump all over the place around region 6.