So, I wondered for a while why would you get bad elements when compiling the AX code using the external parallel compiler (AxBuild.exe) on a clean AX 2012 R3 with CU9.
The error list would be something like:
*** Badlist contains 3 elements.
*** Bad element: \\Classes\AssetBookBonusMethod_IN
*** Bad element: \\Classes\PCImportModel
*** Bad element: \\Classes\VendInvoicePostBatchCleanup
*** Compile log:
The reason for looking into this would be that no Full CIL would pass with classes having compilation errors.
I always imagined that bad element for sure means an error, but knowing that in the past I've seen ghost error messages, I would open up AX and recompile again the elements, but indeed (as it would be normal, since it's standard code) no error is thrown. The Full CIL would generate just fine.
Then, I realized the obvious; I am so used letting the automated tools parse the compiler output, I forget to do it myself when I do make manual compilations :).
So, if you would open up the log file (C:\Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\AxCompileAll.html) written at the end of the parallel compilation process, there would be nothing except the header columns of the table. So wait, no errors, but we have bad elements.
As I have learned (asked on the community instead of actually looking in the code myself) these classes are having the SysObsoleteAttribute on them, and turn out this makes the parallel compiler raise those warning (I consider them just some warnings, no real errors).
So, bad elements on those objects (and who knows, maybe other you can decorate with that attribute) can equal 'warnings', not necessarily errors.