I'm not entirely sure I believe this assertion is valid.

I think v1/v2/v3 index (tileset_layer)->match_types[], which is a dynamically allocated array with no hard limit. In particular, I don't think that it's limited by (drawing_layer)->match_indices, which is what I think this assertion is asserting.

In this case I'm guessing it's firing as a knock-on effect of (drawing_layer)->match_indices having been truncated by the code that's fixed by bug #17095, presumably to less than (tileset_layer)->match_count.

Perhaps it's the case that there can't usefully be more match_types than match_indices; I don't understand this matching stuff well enough to comment on that. If so, the condition should be enforced by an assertion in tileset_read_toplevel(), rather than leaving it to fall through to tileset_setup_tile_type().

Playing a game with the Freeland (small size) tileset results in hundreds of these assertions:

1: in tileset_setup_tile_type() [tilespec.c::3037]: assertion 'v1 < count && v2 < count && v3 < count' failed.
1: Please report this message at http://gna.org/projects/freeciv/

Using this work-in-progress test version I pieced together using the 3.0-alpha version the author released a couple of years ago. http://download.gna.org/freeciv/incoming/freeland-2.2.99-debug.tar.gz