Procedural macros generate tokens, but sometimes the information is kept not in tokens, but rather in the lack of them.
Look at the struct S in the macro below, it doesn't have a pub annotation, so it's private and "private" is desugared into pub(self) where self is the current module, but "current module" depends on the location from which we resolve self.

mod m {
    pub macro mac() {
        struct S;
    }
}

m::mac!();

fn main() {}

If self is resolved from the macro def-site, then the current module is m, if self is resolved from the macro call-site, then the current module is crate root.

The question is what kind of self is implicitly generated for private items from macros.

Unfortunately, as far as I know, the only viable answer right now is self is the module in which the item will end up after all the macro expansions (i.e. "transitive call-site").

There are some alternatives potentially (#40847 (comment)), but if self is resolved from def site, then we'll get "visibilities can only be restricted to ancestor modules" errors and also conservative type privacy errors on every use of the generated struct.
These issues are probably resolvable, but they require nontrivial amount of design and implementation work and we can't delay stabilization of items-without-pub defined by macros until then.