It’d be interesting to find out, if anyone knows someone, what criteria GH uses, here.
I think it’s also good to know who does the work and how it would be maintained. And game out a bit what would need to happen if they weren’t keeping up with it.
Some context on why I think these are important: I’m picking at an unofficial replacement for the community-maintained Travis-CI Nix support (aside: I could use a little help here on well-defined small tasks–message if interested), which should be a stepping stone to asking Travis-CI to remove the semi-official support (and hoping they comply, and hoping the deprecation is smooth…). I’m doing this because the update process is so clunky that no one really seems to want to deal with it, but I think it’s a community-/dev-relations problem to just let the semi-official support rot (and it does, unless your project pins Nixpkgs).
Having Nix in the images would be great, as long as it’s going to keep working. If we have serious questions about that, though, there are advantages to having some form of ownership.
I don’t see it as bad, yet, but I am a little worried about ending up with too many CI flows with too much feature drift between them. Features are great, and experimenting to find improvements is also great, but choices also make it harder to onboard people, and feature drift also increases the switching costs.