The contents of an entity can appear compressed or distorted if the input source member used to bring the entity into Alchemist from external has ISPF profile option PACK ON.
PACK is an ISPF edit macro. Alchemist will take the input file "as is" and stores it as-is. If you browse this entity in Entity Access, Alchemist displays it to you as stored in the ZCL (Zone Control Library). Alchemist does not keep track of the input file parameters such as PACK, NULLS, CAPS, etc. It doesn't manipulate the display in the way that ISPF does.
Alchemist has no trouble simply implementing a source file that is in packed format as well as populating the TFILEs (target files defined in ETD).
However, if the implementation requires Alchemist to interpret the contents of the compressed file, such as identifying the language, it will be unsuccessful and select the default value. For example, a compressed Cobol program will probably be identified as Assembler since that is usually the default in your PCL which could indeed be a problem. You could write PCL to detect a packed dataset using ISPF Edit macros, however, that would increase the overhead of Alchemist. Since the assemble would fail in this example, this can be enough of a check to prevent implementing a packed member when it is not desirable.