I’m not sure I understand what alternative you are proposing. Could you be more concrete?
Keep in mind that nix has no static type system whatsoever. It also lacks statically resolvable identifiers. Things like enums and algebraic datatypes help prevent mistakes in other languages; trying to simulate them in Nix actually encourages mistakes.
Please be careful not to kill this effort with overengineering.
There is a close parallel here to RFC 89, which started out as a nice simple “add a meta boolean to indicate packages that download binaries”. A lot of bikeshedding happened, and what’s been approved is stuck with a bunch of complexity that none of the people active in the PR are particularly excited about, and now the PR appears to be languishing somewhat.
Oh, that already happened. Quite a while ago too. There are already predicates for both of those, and much more, including 8-bit AVR (!).
lib/systems is a bit of a hairball, but lib/systems/inspect.nix is one part of it that is nice and clean and works. Each predicate describes some subset of the platforms (both present and future) nixpkgs might be used with. If you can describe your needs with those predicates, do so. &&, ||, and ! correspond to set intersection, union, and complement. If you can’t, add a new predicate. When new platforms are added one of the duties of the person adding the platform is to go through the list of predicates and make sure they react properly to the newly-added platform – like I did when I added mips64el.
In that sense, lib/systems/inspect.nix is the present/future “rendezvous point” between the set of enabled platforms and packages that wish to query that set.