Even as I've been following the majority of ongoing discussions, I can't figure out the context of the "issue" you're referring to and can't speak to what's going on, so I have to go by your comments in this thread.
Swift Evolution is specifically for user-facing changes to the language, allowing members of the community who are users to weigh in on how those changes would impact them. This provides instantly an answer to one of the most important questions when writing any text: Who is the target audience I'm writing for?
Authors of proposals should try to write in such a way that the greatest number of possible users of their proposed feature (not necessarily users of Swift generally) could give useful feedback about how any user-facing changes would affect them. Any text that is necessary to accomplish that goal should be included, and any text that's not necessary to accomplish that goal should be excluded.
The details of how a feature is to be implemented obviously dovetail with how the user-facing aspects are designed, but proposal authors don't have to explain their implementations beyond what's necessary to understand the user-facing design itself. Indeed, although an implementation is now required before a proposal proceeds to review, further iterations of the implementation occur after acceptance; in fact, there's no requirement that even a single line of code from the original implementation remain a part of the implementation that's ultimately merged.
Implementations of many features are going to be necessarily more complicated than the features themselves. Adding text, even links, about the implementation when such knowledge isn't necessary to understand the proposal is going to alienate users who, as @hborla describes, are fully competent Swift programmers and would likely have useful comments to make, but who may not be up on compiler implementation trivia and who don't have to be.
On the flip side, while educating others on how to implement a compiler feature is certainly useful and worthwhile, I think it's not appropriate to pile this on proposal authors. Implementers are expected to engage with code reviewers about what they want to merge; expecting implementers additionally to field informational questions from folks with varying familiarity with compiler internals is something that they haven't signed up for.
In general, better communication is about meeting each other in the middle, requiring an effort on both sides. Adding requirements produces more communication, but not necessarily better communication: the only thing for certain is that it makes the journey longer on both sides, making it harder and not easier to meet each other in the middle.
One addition to Swift proposals that I've advocated for previously is to bring in a section titled "How do we teach this?" (which I believe was added to Rust RFCs, or another "modern" programming language's analogous procedure). Obviously, such a section should spell out in sufficient detail how to use the proposed feature for a programmer otherwise generally familiar with Swift; part of the process of reviewing a feature would be explicitly evaluating whether it's sufficiently "teachable," and questions about understanding the feature would serve a double purpose during review of clarifying the proposal text and improving a feature's teachability.