Multiple protocols associatedtype name collision

Is it possible to conform to multiple protocols which have identically named associated types? For example:

protocol Foo {
    associatedtype Element
    func processFoo(_ element: Element)
}

protocol Bar {
    associatedtype Element
    func processBar(_ element: Element)
}

class A : Foo, Bar { // ERROR: Type 'A' does not conform to protocol 'Bar'
    func processFoo(_ element: Int) {}
    func processBar(_ element: String) {}
}

I found an old post from swift 3.1 saying this is intentionally disallowed. If that's still the case, I'm curious what the rational is? It seems like this would be a common problem when using multiple modules from different authors.

It is very much possible, but the identically named associated types must be, in the conforming type, fulfilled by the same type.

Your example has two protocols, Foo and Bar, which each require conforming types T to have a type T.Element. You are then trying to write a conforming class A that relies on the compiler to infer the type of A.Element. However, as you can clearly see, you cannot actually write such a type alias explicitly, which is required by both Foo and Bar, since it cannot be both Int and String:

class A : Foo, Bar {
  typealias Element = /* ??? */
  func processFoo(_ element: Element) { }
  func processBar(_ element: Element) { }
}

This is no different from having two protocols that each require a method which shares the same name but different semantics, except that the compiler can't stop you in that case:

protocol IncrementsByOne {
  /// Increments `self` by one.
  mutating func increment()
}

protocol IncrementsByTwo {
  /// Increments `self` by two.
  mutating func increment()
}

struct NotRight : IncrementsByOne, IncrementsByTwo {
  private var _value: Int = 0
  /// There is no way that this struct can fulfill the requirements
  /// of both protocols, but the compiler can't stop me!
  mutating func increment() {
    // ???
  }
}

In the future, there may be syntax added to allow types to conform to two protocols with such clashing requirements, but it adds great complexity in terms of implementation and is not without its own pitfalls for users (for example, it can get very confusing for end users of your type).