I'm making some significant assumptions here, but nevertheless, let's see if it works. The idea here is that since those symbols are not included in tasty, they might as well not exist in subsequent runs which compile different files (without the trees that would spawn them later on). I'm never quite sure how runs interact in repl, so I suspect something might break there. Alternative solution is to tag the specific problematic new Symbols with something to not bring them forward (but that's costly).

fixes #21844, where in the first run lazy val in SuperClass in expanded with additional symbols in LazyVals, and in later runs that tree ends up untouched, those symbols not produced anywhere, but SuperClass members are still accessed via SubClass.allMembers (where the problematic $lzyInit symbols would not be visible when compiling separately).