@rissson The scope of my PR is more similar to Use structured settings for PAM configuration by kwohlfahrt · Pull Request #105098 · NixOS/nixpkgs · GitHub which you built upon. Since yours was a larger rework, I hadn’t looked at it closely.
Now that I have, I can see that we are thinking similarly about many things! A lot of the changes you made are on my todo list if not already implemented.
So far, I’ve focused on lifting PAM rules into the module system, offering a low-level abstraction for defining rules first. My thinking is that if a user has to use the text escape hatch, then they have to throw away all the benefits of the module system. (Imagine a user using five different security.pam settings happily, only to have to write all their PAM rules manually because one need isn’t met by the modules as defined.) Hence the desire to “never need to manually write PAM config files.”
We also want (and to some extent already have) higher-level abstractions for enabling “features” or “modules” that create many rules. These options can be more opinionated and offer useful defaults, like 2FA modules coming after password login. My hope is that I can defer these higher-level design changes until after reworking the rule generation internals.
It looks like your PR addressed both these needs, and our PRs have fairly minor differences in interface design. One area I’ve neglected that I discovered in testing yesterday is defaults, since it isn’t (AFAIK) possible for a user to extend every value in a config attrset.
Unfortunately their wasn’t much traction to make this happen when I worked on it, but hopefully you’ll have more luck!
My burning question for you is: Where did your PR get stuck? How can I make sure I don’t get similarly stuck? It looks like you did great work and documented it well.