This proposal has just popped up in another discussion, and its implications dawned on me.
I see two major issues with the proposal in its current form:
1. Proposal authors shouldn't need to interact with two committees instead of one. It is generally fine to have coordination between committees, so I can imagine a system where GHC SC cannot approve a proposal on its own and must contact CLC when a proposal touches base. Proposal authors mustn't be bothered with the intricacies of this process, they need to write a single document, submit it on a single platform, and then either have it accepted or rejected, whether by GHC SC alone or by a joint GHC SC + CLC committee.
2. Proposal implementors need a single source of truth for the accepted changes. If the proposal document has been marked accepted, it means that it's ready for implementation. Now, I have no problem whatsoever with involving CLC before a proposal is accepted, but once it's done, it's done. It's quite important to be able to point potential contributors to a document that describes the changes we want to see in GHC and its libraries, and it can't be that parts of this document are actually accepted and parts of it are kind-of-accepted-but-non-binding-and-another-proposal-on-another-platform-is-pending.
So I agree with the general idea that it's important to get CLC involved, but for the sake of proposal authors and proposal implementors, this should be a committee-to-committee interaction, not a person-to-two-committees interaction; and acceptance of a proposal needs to be a single atomic operation instead of having kind-of-accepted documents floating around in the ghc-proposals repo.
Vlad