Actually not a bug: constants in a function (at the place of local variables) automatically are global

In trying out an older viper code example:

@micropython.viper
def matmul_vip(first:ptr16, second:ptr16, multiply:ptr16):
    row = const(10)
    col = const(10)
    for i in range(0, row):
        for j in range(0, row):
            sum = 0
            for k in range(0, col):
                sum += first[i*col+k] * second[k*row+j]
            multiply[i*row+j] = sum

I noticed that row and col now are global variables. This happens also in ordinary (not viper) functions.
This prevents e.g. the repeated definition of the same function with another (e.g. native) decorator.
Avoiding const() is not desirable, as it is used by viper and makes the code run faster.
Reading the docs again I now see that const() is described as behaving like a #define in C, so it is taken out of the interpreting process.
So this is not really a bug, but a quite unintuitive feature?
Would it be very difficult to restrict the const() definitions to the function body scope?

No implementation file or test is named. Start by tracing how const() is handled in ordinary and viper functions, and review its documented #define-like behavior; done would mean determining whether function-scoped constants can coexist with repeated definitions and different decorators without losing the stated performance benefit.