This may be an issue where perfect is the enemy of good.
What you’re suggesting is that a simplified runtime type system (for 80% of runtime type checks) is something you still want for your use case. scala-reflect meant to be a 100% solution, and wound up having LOTS of issues because of it. TypeTag is actually one of those issues.
The goal in Scala 3 is what we had before scala-reflect. For use-cases where you only need an 80% solution, you should be able to accomplish that with straight up Java reflection. If you need more, TASTY can provide you the basics. However, we don’t think a 100% solution is something folks need, and it’s unclear if there should be a “core” implementation that is not 100%.
The library you aimed to provide is an example of what we’d like to see come out of dropping scala-reflect. It’d be nice to have a runtime-reflection library that does not implement the EXACT scala type system, but is good enough for the 80% case. Additionally, it should fully document where it “cheats” and what limitations it has. You may have a good start at something that the community could build on for reflection. My only comment is that you might be able to make use of the TASTY data encoded in the class (plus some Java reflection) to grab your type tags from any object, without even needing to grab them in a macro if you wanted to be more reflective (although personally I prefer a tagged approach).