Incrementally compiled code that iterates over Mirror's `MirroredElemTypes` in a macro sometimes dealiases an `opaque` type to its underlying type

[arainko]

Compiler version

3.3.3

Minimized code

The best I could do is a branch on a public project: https://github.com/arainko/ducktape/tree/issue-197-repro

Steps to reproduce:

1. Clone the repository with the branch set to issue-197-repro
2. Navigate to repro.scala (the code should compile if you clean-compiled, it also outputs a compiletime message of the types taken from the destination's Mirror.MirroredElemTypes which reads: Field types: String, Ident)
3. Add a newline anywhere inside object demo
4. The code ceases to compile with this ducktape-specific error:
   Configuration is not valid since the provided type (io.github.arainko.ducktape.scoped.Ident) is not a subtype of java.lang.String @ To.id - it gives us a hint towards what went wrong.
   The aforementioned compiletime message changes to Field types: String, String (Ident is an opaque type over String) - we can deduce that Ident was dealiased to String despite the code being outside a scope where this identity is visible.
5. Clean-compiling makes it behave properly once again.

What's worth noting is that I wasn't able to reproduce the correct behavior of the code if I copy-pasted the offending file to a separate project with ducktape pulled in as a dep. It always fails no matter what I do (on 3.3.3 and 3.5.0).

The code that does the tuple decomposition doesn't do anything that I'd deem 'dangerous' in relation to opaque types (it doesn't .dealias, .widen etc) - it only summons the Mirror of a given type and pattern matches over it (here )

This issue was first reported here: arainko/ducktape#197

Expectation

scoped.Ident is not dealiased to its underlying type.