If lib.evalModules recursively enumerates the entire tree of imports prior to config eval, and each path in imports is uniquely identifable, why does it opt to throw an error instead of filtering the paths of the merged imports list with something like lib.unique?

Is there some behavior of the module system that depends on being able to apply the same import multiple times while building the options attrset?

In reply to@lehmanator:tchncs.de
I want to have several profile configs that all import the same base profile config or nixosModules, but I'd like to be able to import multiple of them simultaneously, which results in an error. My goal is to have each profile work as a fully standalone unit, but also be granularly composable into more featured profiles. Is there some pattern that would allow this organization scheme?

`profile1`:
```nix
config = lib.mkIf config.profile1 {
  # Profile 1 config here
};
```
`profile2`:
```nix
config = lib.mkIf config.profile2 {
  # Profile 2 config here
};