For example the standard Gradle behavior I described / showed in the sample project.
Main Java class files go to ./build/classes/java/main/,
main Groovy class files go to ./build/classes/groovy/main/,
test Java class files go to ./build/classes/java/main/,
test Groovy class files go to ./build/classes/groovy/main/,
main Java resource files go to ./build/resources/main/,
test Java resource files go to ./build/resources/test/,
respective for other languages that might be present like Kotlin or whatever.

Gradle adds all those directories to the class path, but they might not actually exist if there is nothing in their respective source folders if those actually exist at all.
The standard behaviour of Java is to simply ignore invalid class path entries.

WildFly for example had a similar quirk.
It validated Class-Path manifest entries and refused to deploy if there were invalid ones.
We do not need to talk about whether those entries should be there for libraries that a project deploys to Maven Central or similar, they surely should not.
But fact is, that there are various libraries with these non-sense manifest entries and if you use those libraries in your project, your software wouldn't deploy on WildFly where this check was added.
We then had to manipulate the libraries we use, throwing out those manifest entries on the fly when we build our application so that the project deployed.
In the meantime WildFly improved on this and decreased the fatality by only logging a warning if such entries are found, but otherwise ignores it and continues fine.

You can of course also blame Gradle, that they add non-existing paths to the class path and actually I did with a ticket in their tracker, but I'm not sure whether they will change the behaviour.
But whether they change it or not, imho WELD should also gracefully handle that, either like Java does by default in ignoring invalid entries completely,
or like WildFly does now, logging a warning but otherwise ignoring the entries and continue.

If someone gets a warning and ignores it, it is his own fault and he shouldn't wonder if something is not working as expected.
If you think warning level is too low, then log it as error, but still continue and do not abort.
But imho it is wrong to log it as error as it can be exactly what the user wanted, so a warning is appropriate.