Right now there's a distinction between Module (base abstract class), BundledModule and FileModule. However, the only difference between them is that they have different static methods around.

They should be converted to either a record, or an interface with a record implementation, with the current constructors being converted to just factory methods.

I'd say preferrably a record given a Module's data is not expected to be changed by the implementations that use them, and may become problematic if someone decides to do such changes.

Binary safety: BundledModule has a public constructor, that would cause issues if some extension is depending on it instead of using the factory methods. Same for FileModule. And the factory methods in BundledModule return a BundledModule instead of just a module :(

TL;DR: Binary compatibility is difficult.

Actually we can just make a new type and provide a fallback for those types, it shouldn't be that bad, and preferable given else the carpet.script.bundled package would only have a single class...