Protocol B can require the same members as any protocol it refines. This allows the vendor of protocol B to document more stringent semantics for a member than is desired for A (for example, in the standard library, FloatingPoint restates operators in Numeric and documents the IEEE standards relevant to floating-point math). It also allows the vendor of protocol A to add requirements without breaking end user protocols that refine it.
It is more correct to say that Protocol B does require the same members as any protocol it refines.
As such, requiring a member again in a refinement protocol is formally considered a redefinement, as in other type structures, where it is called redeclaration. I understand the exposure purpose, but is it correct to allow such behavior in protocols despite being restricted in classes and other type structures? In the latter, it is not even a matter of restriction, it simply formally counts as a redeclaration and is senseless. Being able to redefine requirements is actually quite misleading, but that is my personal opinion.
What would make more sense, to restrict such behavior in protocols or allow it in other type structures?
I'm afraid I do not fully understand, could you provide a quick example?
Considering it is OK to redefine requirements, what auto-complete shows shouldn't be OK for sure:
Yes, this is deliberate. As I explained, this permits protocols to document refined semantics for existing requirements, among other uses. Protocols are designed to be composed in ways that class inheritance does not permit. A type can conform to multiple protocols which require the same member, and protocols can refine multiple protocols which require the same member. This can also all be done retroactively and in external modules.
Neither would make sense. Protocols are designed to be composed in ways that structs and classes are not.
Suppose the standard library vends a protocol named A, then you create a protocol B: A. You can add a requirement to B named f(). The next version of the standard library needs to be able to add a requirement to A named f() without breaking your existing code.
Xcode is not part of the Swift open source project; you can file bugs with Apple.
This is also very much supposed to be allowed. As I've said, protocols are meant to be composed in flexible ways. A type that conforms to P & P1 & P2 is required by the compiler to disambiguate and supply its own implementation of foo, so there is no problem with using that method in foo2.