>
We could, if we chose, just (continue to) not support "_" in TH.
Do you mean supporting the feature in GHC but not in TH? E.g. if the programmer uses a TH quotation [d| type T @_ = ... |], the generated AST would actually be equivalent to [d| type T @_w1 = ... |] where _w1 is a fresh name? I think it'd be mostly fine, though it would be a lossy conversion, so if the user attempts to preprocess the TH AST before splicing it, they might be surprised to find that their wildcard is no longer a wildcard. In other words, the TH AST is not only produced but also sometimes consumed by user-written code, so I err on the side of representing things exactly rather than via an encoding.
I'm not thrilled about taking such shortcuts because they tend to bite back later, but yes, it could work.
> I'm still leaning towards "do nothing"
By "do nothing" do you mean not implementing @_ which is already in the proposal? This would correspond to "do nothing" in implementation terms, but that'd be a conscious deviation from the spec. The intellectually honest thing to do in that case would be to update the spec to reflect this choice. So the proposal is no good in its current form: it is rather inconsistent to have @_ but not _. We need an amendment, but the question is which amendment: to add syntax or to remove it. Maybe your counterproposal is to remove @_ from the proposal? That would bring the spec in sync with the current impl.
Vlad