Using the idea of a core library being bad when multiple projects depend on it, is like saying you shouldn't use jQuery for the web, libxml in you *nix apps, or any other framework or library. Look at the entire ecosystem of modern development (DRY, OOP, etc) and every single app is built off a set of libraries and frameworks.
What can be bad is if you don't have any type of unit tests, you don't regression test and you don't use any type of API/ABI with your library. If all of your applications have proper tests, your library has proper testing, and you make sure if you break function calls you update api version number appropriately.
For complete coverage, what one would probably want is when changes are made to the Library, you can run a set of tests that will verify the API hasn't been broken, and that the execution of all the code is bug free. Then you can pull in the latest library update into your application and run the same set of tests. If you update the API, then it should be documented so you know what you need to do in your application to update it. Either way, when you run the tests for your application, then you can be as confident as you are in your tests that nothing has broken.