This has definitely been brought up before, but I'm not sure it's ever been made its own thread, so I'm going ahead and creating a thread for it.
Problem: A pack might want to have certain items provided by theme.nxmt consistent for the whole pack, e.g. Lemming sprites. To do this, currently one must set all levels in the pack to the same theme. However, theme.nxmt also affects things such as one-way-walls, pickup skills, builder colors, the background color, which we would probably still want dependent on the level's information, and not the pack's. So if we want to have custom lemming sprites for the pack, but retain other style properties given by theme.nxmt, we must create a theme for every combination of custom lemmings and styles that we might want!
Proposed Solution: A pack could provide a theme.nxmt file that isn't required to be complete. Anything present in the pack's theme.nxmt replaces the equivalent fields provided by the level's. Ranks could also provide these, too, although this would raise the question of what happens if the pack and the rank both provide one. More on that later. This still leaves individual levels out (I still might want the custom lemmings in an individual level, after all!). Theme.nxmt is a pretty small file, though - if we really want to override it in an individual level, we could simply embed one within the level (alternatively, a file with the same filename as the level but different extension). Of course, this would result, as implied earlier, at least 4 potential sources of theme to go through, so how would we decide what gets priority?
I'd suggest going in the following order, where the first item is the one that's processed first, and then each subsequent item overrides the result of the previous operations:
Level's specified theme.nxmt -> Level's embedded theme.nxmt -> Rank's theme.nxmt -> Pack's theme.nxmt
I haven't actually checked if subranks are a thing or not, but if they are, we'd just work our way out starting with the level's subrank to its parent, continuing until eventually reaching the theme.nxmt of the parent pack.
Finally, if we really wanted to be able to stop overriding at a certain point (perhaps we want a specific level's embedded theme to take priority over the pack's), we could mark fields as "FINAL" which would block that field from further overrides.