Thanks for putting this up and for being upfront. I’d like to argue, respectfully, for the fork rather than in-tree.
On the community requirement. This looks like a single-maintainer target for a core that, by your own description, isn’t even listed in some datasheets. It does look like it has “too few users”.
On the precedent (your question 2). If we accept this, we should expect more single-author, low-community, AI-generated targets, and the policy’s community/maintenance bar is exactly what protects the tree from that. I’d rather we hold that bar than relax it case-by-case.
On reviewability of generated code. This is a 117-file change spanning clang, lld, lldb, libc, compiler-rt and the backend itself. For AI-generated code at this scale, the open question is whether anyone understands it well enough to maintain and debug it independently.
In-tree code becomes everyone’s maintenance surface. A fork keeps the cost with the people who benefit until that understanding and a real user base exists.
A fork is the better fit for your actual goal. You built this to serve a specific project; an out-of-tree fork lets you iterate fast without gating every change on upstream review, and don’t impose a cost on 99.999% users that don’t build code with LLVM EZH.
The usual objection to forks is rebase pain. But that’s largely gone now: resolving the mechanical churn (renamed APIs, signature changes) against upstream is exactly what an agent does well — pull, resolve, build, run the target’s tests, iterate. The same workflow that produced EZH can maintain it.