If I'm understanding the pitch correctly, this is just a way to abbreviate types when part of the type pattern can be deduced, essentially just a bit of syntax sugar. As a general matter, I think we focus too much on this sort of feature at the expense of doing the hard work of solving real expressivity and performance problems, of which we still have many.
In fact, when I saw the Generic Constraints section I got excited because I thought it was going to be more than just sugar, allowing us to express the constraint that some type is an instance of particular generic type. For example, this struct would wrap any collection of Dictionarys:
struct Wrapper<T>(x: T) where T == Dictionary<_, _> { … }
The inability to express that today causes cumbersome and expensive workarounds like:
/// Really just a Dictionary; it exists because we can't express the
/// constraint we want.
protocol DictionaryProtocol: Collection {
associatedtype Key
associatedtype Value
/// `self`, with static knowledge that it is actually a Dictionary
var asDictionary: Dictionary<Key, Value> { get set }
//
// Write out all dictionary method/property signatures as requirements here.
// Yes, that's A LOT!
//
}
extension Dictionary: DictionaryProtocol {
var asDictionary: Self { get { self } modify { yield &self } }
}
// Now I can finally define `Wrapper`.
struct Wrapper<T: DictionaryProtocol> { ... }
However, in its full expression, that feature also needs to be able to express more general constraints on T without introducing new generic parameters to Wrapper, which means we need to be able to introduce new named type variables elsewhere. For example, this syntax might express that “T is a Dictionary with Comparable keys:”
struct Wrapper<T>
where<Key: Comparable> T == Dictionary<Key, _>
{ ... }
which of course is just shorthand for:
struct Wrapper<T>
where<Key: Comparable, Value> T == Dictionary<Key, Value>
{ ... }
Because I see no where clauses in the thread, I assume this pitch isn't trying to address any of these limitations. Is that correct?
All that said, I think the risks of adopting the proposed syntax is low, and it fits in well with an abbreviated syntax for solving the more substantial problem I care about, so having registered my dissatisfaction with the priorities reflected, I'm luke+1 
on this pitch. As a practical matter it seems obvious to me that we can't allow the underscore in return type position of public function signatures, and I would prefer not to allow it return type position at all except in closure signatures.
