I would strongly urge you to reconsider your take on this.

Good frameworks follow the Robustness Principle, aka Postel's Law:

Be conservative in what you do; be liberal in what you accept from others.

Utilization of Scala and other non-Java languages on the JVM is rapidly growing. If somebody has an isolated little bit of Scala in their application, even if it has nothing to do with any injectable beans, Weld currently fails completely. I would argue that this is a serious flaw in Weld, even if it's being triggered by a serious flaw in these other languages' compilers.

This is doubly true given that, other than Weld, I haven't come across any other tool that has this problem. I can deploy my application fine in TomEE. The rest of JBoss's detection works fine, including Servlets & EJB 3.1. Given that this issue has a pretty big impact and quite a lot of people use Scala these days, it seems that it would be worthwhile for Weld to be robust against this particular issue—even if it shouldn't have to be in an ideal world.

If you look at the code for Java's getSimpleName, it's clear that there is absolutely no danger in catching this error. It seems perfectly reasonable to me to catch this particular Error with this exact message "Malformed class name" and log a warning, treating the class as anonymous. There are some limited cases where catching an Error is both appropriate and safe.

I haven't read the Weld code yet, but I imagine that you want to exclude both anonymous and local classes. There's a simple and reliable test:

clazz.getEnclosingMethodInfo() != null

The JLS guarantees that this is true if and only if the class is either anonymous or local.

The Scala team has an open bug on this, but this is not a simple issue and impacts binary compatibility. It may not see a resolution soon, but Weld could seemingly mitigate the problem quite easily.