Property wrappers are mentioned, in the first sentence of this thread, as the initial motivation of this pitch:
It would be good to tell if expanded parameters are a necessary step towards sharing property wrapper storage. People who want shared storage, but do not like this proposal, could change their mind, or suggest alternative ways to reach the same goal.
Autocomplete is indeed part of the tooling of developers who interact with code. Another part is navigating to initializer and method definitions, and yet another is displaying documentation of initializer and method definitions. Both help accessing important information.
I'm not sure I understand what you mean. Each overload would have one location, and IDE can jump right to it.
And even if this were true, what about removing difficulty, instead of adding some? Designing APIs for screenshots instead of developer experience sounds ill-advised to me. When I say developer, I think of the end users of APIs, not the API designers.
This pitch is not balanced. It favors API designers over end users.
When considering an overloaded API like the ones mentioned in the proposal and this thread, the fact that those different parameters will lead to the initialization of a value with the same underlying type is hidden from the user. With expanded, this underlying initialization is explicit and I believe it makes code easier to understand.
Again, I'm not sure I understand what you mean. Nothing tells me, when reading code, if I'm looking at an overload or an expanded parameter.
And again, this assumes that overloads are the correct API with the current Swift, and that the language needs a new feature in order to help people who design such APIs (note: IMHO, it helps those people, but not the end-user developers, and I wish the initial need was questioned in the first place).