Except it clearly is possible since I and millions of other developers seem to manage it daily.
> Also, dynamic languages all require you to fix calls to changed functions. But at least, when you test that code, it won't accidentally seem to work when it is broken.
This is a problem of your code-base, not the language. If your code is so brittle that it can't stand a few function changes without collapsing into a miasma of shit, then whose fault is that? Of course you need to fix calls to changed functions - but if doing so is causing you and your team pain, then perhaps you have other problems.
> This doesn't sound potential at all. It sounds like you either lose a huge amount of reliability, or add a huge burden to development.
Of course it's potential. Nobody's forcing you to write tightly coupled, shitty code which breaks after every merge. Seriously? Figure it out.
> What do you gain here? You save an asterisk in the syntax when you want to overload?
Like I said before, squishiness.
> In a collaborative environment, we merge work with each other every single day.
As do I, and clearly millions of other developers who don't seem to run into your problems.
> Do you have documentation and release notes for every commit you publish?
We have proper commit messages and tracking codes for every task / bug, yes. There's no such thing as perfect information - and sometimes merges get messy - but this is not unique to JS. Sure, not every single commit is perfectly documented, but small commits and concise messages go a long way to ensuring that the history is traceable and the code is clean. The more often you commit and merge with your collaborators, the more in lock-step you are and the less likely you are to run into these kinds of issues. Messy merges will happen from time to time regardless of your preferred language.
> Do you go and check the commit's release notes every time you pull?
Not always, but often. Maintaining visibility of the trajectory of the code and the project as a whole will help massively in heading off risks and development issues.