Nice.

This implementation has the same two-step scope lookup as stage1, including the flaw noticed in #7141.
I'd expect the stage2 compiler to implement the correct shadowing logic, or are we playing the "It doesn't have to be perfect" card?

I just used the logic from the identifier resolution code here, so if we want to implement the more "advanced" lookup logic we should probably abstract it into a "lookup" function and then use it in both places.

It's not a "basic" vs "more advanced" thing, it's a "according to the specification" vs "stage1's behaviour" case.
Keep in mind that a lot of code will be broken by this change, don't forget to buckle up.

The problem with stage1 is that declarations only look for redefinitions in the same container, not with local variables.

The logic looks OK to me here. Let me clarify the language specification (cc @SpexGuy):

Declarations are allowed to collide, so that it is possible to declare, for example, both of these:

• a.b.c
• a.c

pub const a = struct {
    pub const b = struct {
        pub const c = struct {};
    };
    pub const c = struct {};
};

This is allowed, however, ambiguous references to c would be a compile error. So, inside b, one must use a.c or b.c in order to refer to c. Referring to c directly would be a compile error.

Parameters and local variables are never allowed to shadow anything, including each other, or any declarations, no exceptions.

So, if I understand correctly your example, #7140 is legal but the use of print inside print should trigger an error?

Yes

#678