First of all, we don't specify the definition of a function in the subsequent detailed section if it's already fully covered by the container requirements. Do you have an example where a function is not described, yet it's not covered by the container requirements?

The other concern I'm reading here is that we show a parameter name "il" in the synopsis of a container, yet there is no detailed specification (because the function is covered by the container requirements). That seems an editorial inconsistency, and a patch to remove the "il" from the declaration in the synopsis for those cases would be welcome.

We might be missing some overall policy here. I think we agree that parameter names should be consistent between the synopsis and the detailed specification (if present).

For other functions: For parameters with a unique type (e.g. initializer_list), it seems a parameter name does not add comprehension value. (That's different if two or more parameters have the same type, e.g. when a pair of iterators is used; calling one "first" and the other "last" is helpful.)

I don't see a need for such a blanket rule. Is there actually a problem to be solved?

The parameter names only have meaning in the detailed description where we refer to those names, otherwise they are purely informative. "position" and "first" and "last" inform you of the intended meaning of an iterator parameter, "il" does not tell you anything useful. If we need to refer to il in the detailed description, it needs a name in the detail description. Otherwise, it doesn't. Either way, an initializer_list parameter doesn't need a name in a non-defining declaration in the synopsis, and I see no harm in omitting it there. Is there a reason they need to be consistent?

I would argue that it's just less comprehensible to those who're not familiar with the very specific ruleset belonging to the inclusion/exclusion you are describing. Just writing new standardese is made more complicated by having to understand an additional rule here. The fact that we're even having a discussion about it is an indicator of that.
I prefer simplicity. Maybe we don't need a blanket rule across all parameters (however useful that might be to comprehension, it would be an onerous task), but I think parameter names should be consistent between the synopsis and the detailed specification. Otherwise it triggers a 'wait, but why...' in every newcomer.

But it doesn't matter for new standardese. If you want to name so your parameters, do that. If you want to omit parameter names where they aren't used or referred to by any detailed descriptions for a function, do that. LWG are not going to reject proposals on that basis. It doesn't matter, and so I don't see why we should decide on a rule and then change existing text. Making a rule that then has to be followed is more work and something extra to know.

Consistency between synopsis and detailed descriptions makes sense, but I'm not convinced anything beyond that solves a real problem.

But it doesn't matter for new standardese. If you want to name so your parameters, do that. If you want to omit parameter names where they aren't used or referred to by any detailed descriptions for a function, do that. LWG are not going to reject proposals on that basis. It doesn't matter, and so I don't see why we should decide on a rule and then change existing text. Making a rule that then has to be followed is more work and something extra to know.

When I said it makes a difference for new standardese, I'm referring to having things consistent between synopsis & descriptions. When someone like me is trying to adhere to the standard norms, sees that these are consistent, it provides a firm basis for writing. If they're not consistent, it's just confusing.
It sounds like we can wrap this up by saying there should be a patch to make the current inconsistencies between synopsis & descriptions consistent, and leave it at that.

Editorial meeting consensus: No change is needed here: Having unnamed parameters is widely done and is fine. We aren't consistent about whether an otherwise unused parameter should be named, but that's not in scope now. And as long as we don't use multiple different names for a parameter, there's nothing overly confusing here that needs addressing.