I don't know about the size of their codebase or the extent that it has consumers outside of the repository the author has access too, but once a code smell lik

I don't know about the size of their codebase or the extent that it has consumers outside of the repository the author has access too, but once a code smell like this has been identified, it seems a bit strange not to just eliminate it completely straight away. The hacks he describes seem like a good first pass to identify how much of the code relies write access rather than just read-only without having to change all the legacy code, but IMHO it'd be better to just move the member into the private section and then fix up the compile errors that produces. Sure, fixing up all the compile issues requires a bit more upfront work, but it stops anyone else using the deprecated interface, and makes the design a bit more consistent when all access is done the same way. Having identified the legacy code use and then shoving it under the carpet just makes this someone else's problem in the future, and they will have to waste some time to go down a similar discovery path, potentially discovering an even bigger problem at that stage.