I honestly think it's hard for "Nix to Nix" simply because by trying to make everything reproducible, it is dealing with more of upstream's garbage, and "reifying" the hoops that people jump through doing sysadmin things in code looks scary.
I really want more upstream developers to use Nix, so they might loose their myopia, and start thinking of the the FOSS ecosystem as a whole, and not just their own packages within it. Nix is the best way to get the bird's eye view, I am sure. Just try not to gag at what you see!
[1] Though I still maintain that contributing to Nixpkgs is much easier than contributing to e.g. Debian or Fedora.
At the end of the day, I much prefer trusting upstream than having to trust packagers to do everything right.
Since the issue was first closed, there are some solutions for NixOS that I hope for discoverable. For Nixpkgs alone, I really don't think see any solution that is both secure and ergonomic -- setuid is bad.
More than that though, the mentality that you can just patch away critical features (like setuid) without telling the user is imo unhealthy for an OS.
Upstream is clearly wrong here - whether that means slock should be patched to be sane, or that slock should just not be packaged at all, I couldn't say.
- Makes different systems behave differently - this makes bugs harder to track and confuses users
- Moves the trust from the software developer to both the software developer and packagers (who may not have the same expertise that the developer has)
For ex. #1: When you use software like slock, you presumably trust slock to do its job well. If you don't trust him enough in his choice to add setuid, then why would you trust him enough to use the screen locker?
I understand adding patches that are strictly packaging related if upstream is uncooperative (mostly I guess because nix is small), but changing behavior is another ballgame.