IMHO, the most obvious solution is that the bind should be available only inside case block and if you need to change a global or a nonlocal you do this explicitly inside the case block,
Do you mean
case x: x = x
if this is the case you can pickup a bind name that doesn't shadow the desired variable.
But you can already do that in the case clause itself.
This way the intention to overwrite a global/nonlocal is clear in code
But you can't "overwrite" a global or nonlocal without a declaration. You can only shadow it, and as I wrote above, if you want to avoid shadowing that global or nonlocal you choose a different name in the case clause.
Regarding the proposal itself, it's a major change, because that's not the way binding works anywhere else in Python. There are two differences. The first is that there are no statements besides class and def that create scopes, and the other two scopes that I know of are module and comprehension (I seem to recall that comprehension scope is based on the idea that the code inside the brackets is actually syntactic sugar for a generator def, so that special case would be derivative of function scope).
The second difference is that you can't change the binding of a name in an outer local scope without a nonlocal declaration. That means if case scope follows that rule and you want to have a binding inside the case scope that persists outside it, you'd need to declare it. Probably you don't want to have to declare those "external" names, so the names bound by the case clause would be very special. I haven't thought carefully about it, but it seems to me this could be a bug magnet.
So, you could do this, but it would make scoping much more complex than it currently is, and require a lot of redundancy (every binding you want to preserve for later use would need to be made twice, once in the case clause and again in the case body). And I don't think it's that useful. It doesn't help with the I18N problem, since you might want to use a marked string in the "case _" suite. And the main complexity from the current scoping rules comes from the fact that it seems likely that different arms of the match will bind different sets of names, so NameErrors become more likely in the following code. But your proposal doesn't help with that, and may make it more likely by proliferating names.