Now, it's certainly true that nameeq() doesn't need a collation spec today, any more than texteq() does, because both types legislate that equality is bitwise. But if we leave ExecBuildGroupingEqual like this, we're mandating that no type anywhere, ever, can have a collation-dependent notion of equality. Is that really a restriction we're comfortable with? citext is sort of the poster child here, because it already wishes it could have collation-dependent equality.
There already seems to be a policy that individual types are not allowed to have their own concepts of equality:
postgres=> select 'NaN'::float = 'NaN'::float;
?column?
----------
t
(1 row)
postgres=>
According to the IEEE floating point specification, this should be f not t.
To me, this suggests that we have already made this decision. Any type that needs an "almost but not quite equality" concept needs to define a custom operator or function. I think this is a reasonable approach to take for collation-related issues.
Interesting relevant Python observation:
>>> a = float ('NaN')
>>> a is a
True
>>> a == a
False
>>>
So Python works quite differently from Postgres in this respect (and many others).