I’m not aware of anything discussion the pros and cons of Stuart’s approach and while I have huge respect for Stuart’s work, with some trepidation, I think I would have to disagree with his suggestion. However, I’ve not yet watched the full video, so perhaps I’m missing some crucial point.
I think what is really underlying Stuart’s position is ultimately about expectation management and the reason I don’t agree with his suggestion is I don’t see it having any significant improvement in the current situation. In fact, I feel it just substitutes one set of issues for another.
My own position is probably closer to that of the response from @p-hinik and why I feel it is essentially about expectation management. Stuart seems to be expecting more from semantic versioning than me. For me, it really just provides a guide as to what level of effort I can expect to invest when updating a dependency to a new version. If the version only represents a bug fix or minor version change, I expect minimal effort is required and that there are no API compatibility changes. If on the other hand, there is a major version change, then all bets are off and all I can assume is there are major changes which most likely will break things. In either case, there is no substitution for comprehensive testing after updating a dependency.
Versioning in any form is a challenge. Semantic versioning can provide some valuable additional information to clients of a library. However, depending on the complexity, size and breadth of change between versions, it can be extremely challenging to get it right. It can be easy to miss a change which has broken API compatibility in a subtle way or just miss one because of the number of changes or fail to recognise when one of your own dependency changes bubbles up to require a major version change etc. In one of my JS libraries, I’ve had issues logged because I increased the major version number and a user could not find any breaking change, so felt changing the major version number was a mistake. Again, an expectation mismatch.
Stuart’s solution feels a bit like a response based on an expectation that the semantic versioning would somehow protect against things blowing up when there is a major version change. I’m not sure how this could be and I don’t see how using a different name, whether it is a different library name or a different namespace reference name, changes things. If foo() from a new version of the library is going to blow up in my application, whether the library has a new name or is imported with a new namespace reference is irrelevant, it will still blow up. In some senses, Stuart’s approach is even worse, from a maintenance/change perspective as it will likely require more changes sprinkled through my code (everywhere the namespace is imported compared to just the deps) and in the worse case, could result in some weird situation where my application is dependent on two versions of a library at the same time, which in itself could introduce weird issues.