Wow! C appart, and fixed arrays appart, I didn't know V permitted to set non-constant match options!
This code is accepted:

fn check(a int, b int, c int) string {
	return match a {
		b { 'b' }
		c { 'c' }
		else { 'other' }
	}
}

fn main() {
	println('${check(1,1,1)}') // b
	println('${check(1,0,1)}') // c
	println('${check(1,0,0)}') // other
}

even though in check(1,1,1) call variables b and c are equal which is not permitted normally.

Next code is rejected but is weird:

fn check_2(a int) string {
	return match a {
		a { 'first a' } // accepted line (but why?)
		a { 'second a' }  // ofending line
		else { 'else' }
	}
}

produces:

match case `a` is handled more than once

Well, a will always match a...

You a, b, c example works because they are separate variables, even if they have the same contents. Otherwise, check(1, 1, 2) wouldn't work, neither would check(2, 1, 2), etc. check(1, 2, 3) will fall into the else, since the contents of a don't match either of the other 2.

In fact, you can match on ranges, on the results of fn calls, etc. - anything that matches the type of the variable you're matching against.

This code is accepted and always prints a. Never 1, never else... even though the programmer thinks they would be possible.

fn check_3(a int) string {
	return match a {
		a { 'a' } // accepted line (but why?)
		1 { '1' }
		else { 'else' }
	}
}

This program can print 1, otherwise just a, but never else because I moved 1 as first match!

fn check_4(a int) string {
	return match a {
		1 { '1' }
		a { 'a' } // accepted line (but why?)
		else { 'else' }
	}
}

Incorrect. It will only print 1 if you call it with check_4(1). Otherwise, it will print a, since a always matches a.

fn check_4(a int) string {
        return match a {
                1 { '1' }
                a { 'a' }
                else { 'else' }
        }
}

println(check_4(1))
println(check_4(2))
println(check_4(3))

output is

1
a
a

Your check_3 will always print a, because a always matches a, and that is checked first.

JalonSolov: For fn check_4(a int) string { I said the same you said. Anyway, imho the possibility of dead code is important so I open issue #23404 to consider to send a warning.

Returning to the origin of this post, seems to me the branch of 0 is dead code, because never [0,0]! will be equal to [0,1]!:

fn on_event(e &gg.Event, mut app App) {
	_ := match [0, 0]! {
		[0, 1]! {
			0
		}
		else {
			panic('')
		}
	}

Yes, if and only if the compiler accepts such fixed array as comparable variables.