Yeah, but that relies on a lot of "ifs" when a bugfix is done.
If the services don't have tests before deployment, you'll have problems.
If a rarely-updated service doesn't get the fix, you have problems.
If someone got lazy and didn't upgrade (how is that even possible? they don't have to do anything to get the new thing other than rebuild, redeploy) you'll have problems.
OTOH, there's no "ifs" about getting a bugfix when they're all using the same copy of `someFunction()`.
When they're all using the same copy of `someFunction()`, the bugfix will go in with the next build of their service, without them even knowing.
After all, you don't have each team keep their own copy of the kernel, do you?
So you can make a new function. Maybe one calls the other. They do nearly the same thing but not quite. Some dependencies move to the new one, some don't.
Or you version the library. Shortly after, people want mixes of behaviour from different libraries, and someone else wants two dependencies that each want different versions of the library.
I don't have a good recommendation here but silently changing the behaviour of libraries is not necessarily a better play than not doing that.
edit: Libraries don't solve this, to be clear. Let's say you have 100 services that reference `someUtilityFunction()` in SharedLib==1.0. Oops, there's a bug! OK, let's publish SharedLib==1.1. Great... now you still need to go and update, test, and deploy 100 different services, because they're not going to pick up the corrected business logic otherwise. And of course, you might have the case where someone got lazy and didn't upgrade and they're still using SharedLib==0.0.1-alpha, and there's a bunch of breaking library changes that happened between that version and 1.0 that were never implemented...