My experience is that users who are trying to get work done will bypass every speed bump you put in the way and just access your internals directly.
If you "just" rely on them not to do that, then your internals will effectively be frozen forever.
I seriously do not get this take. People use reflection and all kinds of hacks to get at internals, this should not stop you from changing said internals.
There will always be users who do the wrong thing.
I can't break their app without them complaining to my boss's boss's boss who will take their side because their app creates money for the company.
Having actual private fields doesn't 100% prevent this scenario, but it makes it less likely to sneak through code review before it becomes business-critical.
That doesn’t save you in languages that support reflection, but it will with zig. Inside a module, all private does is declare intent.
In languages with code inheritance, I think inheritance across module boundaries is now widely viewed as the anti-pattern that it is.
Or they will be broken when you change them and they upgrade. The JavaScript ecosystem uses this convention and generally if a field is prefixed by an underscore and/or documented as being non-public then you can expect to break in future versions (and this happens frequently in practice).
Not necessarily saying that's better, but it is another choice that's available.