As part of T98087, by default modules will use compute their version based on building the module and hashing its produced content.
However for the most common module, FileModule, I estimate this would slow down version computation by at least 10x. This would make If-None-Match/E-Tag handling of module responses too slow. And not to mention the startup module.
This is mainly due to involvement of preprocessors like Lessc that should only be invoked when necessary. While we can't prevent that in a generic way, we can have specific overrides for the FileModule.
Hashing only the files specified in the module is not sufficient because less-files may import other files. And CSS files reference images.
The logic for detecting changes is already in place from the timestamp-based system. Basically, when a module is build, it stores all files it had to access along the way in the database. Then, when computing a version, we check those files in addition to the files currently specified at the top level in the module definition.
It stands to reason that a module can only be different when one of the top level files changed, or when one of the previously known included files changed.
These references being tracked in the database is slightly suboptimal, but has been status quo for a long time and isn't an immediate concern beyond complexity (T90001).