Moving from Microservices to Monolith, an interesting reading

Came across this interesting article:
https://segment.com/blog/goodbye-microservices/
To put it short, the microservices model resolves the head-of-line blocking problem by creating a separate service and queue for each destination. A natural transition followed is to break out the code for each destination into their own repos. However, as they have more destinations/microservices added, the library version will diverge across multiple destination code bases. The operational overhead increased linearly with each added destination to maintain the compatibility and fix all broken tests. So they go back to Monorepo and maintain the same version of dependency across all destinations.

From the description of their shared library design, I think it only has a loose coupling. That's why the versions diverge. If they enforce a more strict coupling in the application/destination code design, most of the discrepancy should be able to bypass. Moreover, if they can maintain the same version of dependency in the Monorepo design, then it means they can maintain a single shared copy of the library, and why don't do it from the beginning?

As a related solution, they may use the Istio service mesh to help manage all these services:  https://kubernetes.io/blog/2017/05/managing-microservices-with-istio-service-mesh/ However, it mostly addresses the metrics collection, tracing, and management views. I don't see how it can handle the shared library dependency problem across a large number of microservices.

A similar discussion on shared library dependency is discussed here:
http://www.grahamlea.com/2016/04/shared-libraries-in-microservices-bad-advice/
In short, we want to avoid deploying shared libraries between application on the same host, so that the dependencies can be upgraded independently. There're also many other articles out there if you search for "microservices dependency hell" online. The basic ideas are similarly built around the decoupling of dependencies and limit the microservices interactions.