Currently, the grammar for function types is as follows:

functype      ::= (func <paramlist> <resultlist>)
paramlist     ::= (param "<label>" <valtype>)*
resultlist    ::= (result "<label>" <valtype>)* | (result <valtype>)

All parameters and results must be named, except a singleton result.

There is broad variety across programming languages in whether and how they allow/require/distinguish named vs unnamed parameters, as well as unnamed vs unnamed results, at a function's def site, use site, or both. The current design is rather specific in that regard and somewhat biased. From purely an interface perspective, there is no reason to treat parameters differently from results, or allow omitting names in some cases but not others. And at least for some languages, it would be useful to make explicit which components have "proper" names and which ones haven't, since that enables more idiomatic bindings.

See here for more discussion.

There are several degrees to which the grammar could be generalised:

paramlist     ::= (param "<label>" <valtype>)* | (param <valtype>)
resultlist    ::= (result "<label>" <valtype>)* | (result <valtype>)

or

paramlist     ::= (param "<label>" <valtype>)* | (param <valtype>)*
resultlist    ::= (result "<label>" <valtype>)* | (result <valtype>)*

or

paramlist     ::= (param "<label>"? <valtype>)*
resultlist    ::= (result "<label>"? <valtype>)*

I'd suggest one of the latter two, which make names uniformly optional, and then specify a canonical scheme for synthesised names in contexts/bind-gens that need them, for example, "_1", "_2", etc. based on position. This would apply symmetrically to parameters and results.