It seems to me that the only motivation for this proposal is for Template Haskell generated code. So maybe we can imagine an alternative that is purely in Template Haskell, without any syntax. Which would avoid the concerns about parsing pragmas*. Maybe there is room, in this space, for a generic mechanism, but I don't think that we'd need this: it makes sense to let the Template Haskell slice decide if a record it defines generates selectors or not.
That being said, I'm personally ok with the proposal as it stands, I think it makes sense. But it's likely that a pure Template Haskell solution may be both more forward compatible and easier to implement (at least, based on Vlad estimate, who knows this part of the code, I'm inclined to believe so). As there doesn't seem to be any particular motivation beyond Template Haskell, I'd be ok if we made this counter-proposal.
I don't think counterargument 4 is something we can oppose: it is theoretically possible to define the doppelgänger record in a separate module, but we know it won't happen. Matt Parsons mentions the Esqueleto library, it is obvious that the library will prefer using a silly name for record fields rather than ask its users to move definitions to another module and the library will be right: it is less obnoxious.
All in all, I think that the proposal is quite reasonable, and would open space in the design of Template-Haskell based libraries.
* For the record, I don't think that we can claim that pragmas can be ignored semantically. The OVERLAPPING pragma is a counter-example. Maybe more acutely: the LANGUAGE pragma. So I don't agree with counterargument 3.