As a general observation, MLIR positions itself as a partly productivity-oriented compiler framework. If one of the original goals was not having to write n-th CSE implementation for each compiler (see early presentations from Chris), I don’t see why we at the same time encourage users to write n-th IR “expander”.
I don’t know what folks need in general, my proposition is abstracting from what we have in-tree and several TF-related projects. By putting this up for discussion, I hoped to receive some feedback on what else is necessary or simply useful.
As a matter of fact, I agree that fragmentation is inevitable. Therefore, I am trying to find ways to minimize its cost.
Maybe we can actually reduce this discussion to what is considered to be LLVM standards and which parts of the proposal contradict those standards, so we can discuss those parts separately.
I don’t fundamentally disagree with this. But there is cost to everything, roll-out duration and api churn will affect most users here.
LLVM and derived projects (including translation in MLIR) uses llvm::IRBuilder API to construct (most of) the LLVM IR. Should MLIR adopt the same API pattern, i.e. Builder, only for the sake of having the same API patterns as LLVM (see “standards” above).
They were also landed because they were, and still are, used. That’s why I am trying to converge EDSC and Builders and reach a state where we have one thing that is good enough for everyone. The alternative at this point is to keep the status quo.
We’ve gotten so meta in this discussion that I would like to see what are the ways of mitigating the risk, regardless of EDSC or this proposal 
As you probably know, EDSC is a combination of many different things. I am trying to progressively integrate them with the rest of the infrastructure as explained in Evolving Builder APIs based on lessons learned from EDSC. In his posts above, Chris argues that even the current proposal is too broad. Considering such helper structures is definitely out of scope here. For practical purposes, such helper structures will likely remain unchanged in the first iteration and have their constructors updated to take a builder if we decide to remove edsc::ScopedContext. Let’s not derail this discussion even further though.
To be honest, I don’t understand how affine structures are modeled in MLIR without digging deeper, and I would guess neither does the majority of the contributors. This does not preclude them from being in tree.
I listed some examples in my previous answer, each word is a different link:
I can’t even imagine the amount of pushback I’d would have received had I proposed to replace builders and EDSC by a completely new API; nor the amount of work to do. If we want progressive change that does not introduce more divergence, components need to interact with each other.
It seems like both you and @stellaraccident have some ideas about higher-order builders. I am interested to hear them and potentially incorporate them in the proposal.
The signature of the function is template <typename OpTy, typename... Args> OpBuilder::create(Location, Args &&... args), which means it accepts just about any argument list. While I think it’s technically feasible, although not trivial, to discover that the argument pack is forwarded through another function template with variadic template parameters to a method on a dependent type, and use the list of possible overloads of that method as helper prompt, I would consider this to be too niche to be included in clangd. Even if it is included, it only gives you the documentation, implicit conversions are not triggered (they are in @jurahul’s proposal and in mine).