"advocating accessing private internals of 3rd party tools in new open-source projects": no - I didn't advocate that as it's obviously insane :)
I said advise your users and trust they won't do insane things. This allows your users to patch/hack in their application code, as a temporary or exploratory thing. I didn't suggest releasing libraries that themselves monkey-patch dependencies (ugh).
Not really, it's the same thing except from the other point of view. If you allow people to patch/hack in their application code, then someone will patch/hack in their application code without telling you (because it works and they're under time pressure), then once you change something it will break.
Exactly this. Whatever you allow people to do - they will, at some point. At some point, monkey-patched code gets used in someone's library, at some point they put it on Github, and at some point it gets forked.
The OP is literally suggesting replacing "private" with either "public" or "protected" in C++ code, and then expecting comments/documentation to communicate what was already communicated previously by "private".
I said advise your users and trust they won't do insane things. This allows your users to patch/hack in their application code, as a temporary or exploratory thing. I didn't suggest releasing libraries that themselves monkey-patch dependencies (ugh).
You're straw-manning.