"why" can be pretty nebulous too. For a larger, widely used project, the question isn't "why" make something internal, but "why not". The safe default is to n

"why" can be pretty nebulous too. For a larger, widely used project, the question isn't "why" make something internal, but "why not". The safe default is to not semi-permanently commit every half baked bit of code to the public stable semvered API boundary to support for who knows how many years, but to only do so after careful consideration and justification. To add this disclaimer to every single bit of internal code is to drown your codebase in a sea of redundant comments - none of which are specific to the code, or even the codebase, but are instead rehashing "why encapsulation?" 101. This will only train readers of your code to ignore the low-value low-signal comments, and they will then end up asking the same question anyways, and "read the comment that's right there!!!111oneoneone" will be a fustrating experience for everyone, although they might not be able to articulate why. The real question I'm curious about here isn't "why are internal things internal" - but why this internal thing must technically be public. Does this predate ES6 symbols? Is there a plan to switch to those at some point in the future? Is there a tracking issue? Or does this need to be accessed from elsewhere in a manner that makes Symbols awkward to use? Where?