I think the problem comes in when the shared library is used to provide some kind of baseline service, so that if changes are made to the library and 2 services using them are out of sync, then chaos will result.
The solution you advocate is correct. Service boundaries need to be well defined and well separated.
In what way? Versioning helps pin shared libraries so they are not inadvertently updated. However, when you have 2 services A and B using the same library, changes to the library, if they are not updated in both services, may lead to the services being unable to talk to one another. e.g.
Suppose service A and B use library L. But the authors of library L decided to rename a certain field in the JSON of HTTP calls that are crafted by the library. Now, unless both A and B update to the new version, they may not be able to talk to one another, so each has to coordinate their efforts to either hold off using the new version, or deploy the new version at the same time.
> But the authors of library L decided to rename a certain field in the JSON of HTTP calls
The API endpoints should be versioned as well. Once all services have been upgraded to use the next version of the API, the previous endpoint can be deprecated.
The solution you advocate is correct. Service boundaries need to be well defined and well separated.