I think the question to ask is, are these proposed policies good ones we’d like to have? If so, would we like to have them at the LLVM project level?
I see @clattner’s point that it makes sense to propose (and implement) such policy changes at the project level. But the discussion in New requirements for committing to main branch shows how controversial well-meaning changes (e.g. “everything should be reviewed”) can be.
The libc community is still fairly small, and we have the opportunity to adopt practices that we think are good for the libc project, even if they diverge from the LLVM project as a whole. But I think it can be easier to make positive changes to LLVM commit policy by first adopting those changes in smaller sub-projects – i.e., grow the new policy upwards and outwards, rather than all at once from the top down. This also makes it faster and easier to tune the policy before it gets adopted broadly: if there are problems with the policy, it’s better to discover them and fix them in a smaller community like libc than one as large as Clang.