the other reasonable alternative is to make it equivalent to map (name: [ name set1.${name} ]) (attrNames set1) == map (name: [ name set2.${name} ]) (attrNames set2) but this is:

1. I think inevitably strictly slower in terms of runtime perf because there are cases where you will recurse into expensive thunks that the other variant never will
2. more difficult to express in terms of in-language primitives
3. less compatible - for every program that returns true or false from such a comparison, the other variant will also return that value, but this variant will abort/loop forever/throw strictly more often

both of them are entirely consistent with "angelic" choice of nondeterministic comparison orderings, but I don't think the interleaved variant has any merits

other reasons comparing names separately makes more sense:

1. consistent with lists, [ abort abort ] != [ abort ] compares lengths before values already, and list lengths are analogous to attrset key sets
2. indeed the interleaving version can't legitimately even short-circuit on the number of names without complicating semantics because of { a = abort; } != { b = abort; c = abort; } -- whereas if you compare names first, you can legitimately do that short circuit because attr name set comparison happens before any thunks are forced

In reply to @piegames:flausch.social
sky1e: What are your plans for the Value outParam CLs? Will you migrate everything given enough time? (Though not sure if migrating all the primops would be a good idea …)