> Things that you might want to put into the narrative:
>
> - Given that several function declarations may have deviating
> parameter names, choosing which one to take is a question.
> But that has been conceptually addressed by reflection
> (take the unique one, otherwise there is none).
>
> - Exposure of function parameter names from the standard library
> is also conceptually addressed by reflection.


Yeah, maybe the draft doesn't make it so obvious, but our approach to
declarations with different parameter names is the same as for parameter
name reflection.

As for standard library functions, they already have a bunch of properties
that are observable but which we don't bother to keep stable like:

   - Exact expression validity/invalidity (detectable with
   requires-expressions).
   - Forming function pointers or references to functions (except for
   addressable functions).
   - Explicitly providing template arguments (in <algorithm>).
   - Reflecting on parameter names and other properties (although I'm not
   sure we have a policy for this).

Furthermore, the parameter names in the implementation all use reserved
identifiers, and we could recommend a warning when a reserved named
argument is used, like f(.__x = 0). Consequently, a library-wide policy of
not supporting named arguments would be trivial to implement.