The List of all Elm kernel functions topic doesn’t discuss ES modules much: There’s one comment that says that ES modules leads to better tree shaking and therefore less code shipped to clients, and another that says that Elm already has very good tree shaking so it doesn’t matter.
The topic does not mention caching, though. I agree, it intuitively feels like it would be a good thing if you didn’t need to download all the compiled Elm JS just because there was a tiny change on just one page.
In --optimize mode, Elm shortens all record fields to single letters. This means that just by adding one new field on one page, all other fields in the app might get new one-letter names. Then you’d need to download new versions of all modules anyway. So in a world where the compiled Elm JS can be split into multiple modules for caching, that optimization might not make sense anymore. The Lamdera compiler has a --optimize-legible flag that skips the field renaming.
Then you’d need to work out where to split the code. Does the compiler do it automatically somehow? Or do you annotate the code to show where you’d like the splits?
Finally, if this happens people might want modules to be loaded as needed as well. In the React world, code splitting allows downloading more code when you navigate to a new page of an SPA, instead of downloading it all at once on the first page load. Then we have a new dimension of things to work out.
And as Rupert said, measurements would be needed to check that it actually improves things as well. It might depend on the website: If you have a website that people visit daily you might benefit from the more granular caching. But if they visit monthly, maybe all cache is stale or purged anyway.