The contradiction is in your title. Google drive is not a version control tool! It is a cloud service. SVN, git, … are version control tools.
Having global libs does not violate being able to share or version control a project. You just need to have the same global lib setup at all the machines where you intent to work on.
As long as you include the cache lib you are even able to view the project in any state on any machine without thinking about global libs at all. (Worst case you need to rescue the schematic before viewing. Not a problem for pure viewing but would be annoying if you make changes.)
Without proper version control you will need to keep global libs rather stable as you otherwise will get into trouble when you want to continue working on a project you finished half a year ago. (One of the reasons why version 4 to version 5 migration is rather hard is because we reorganized the full official library.)
Especially with regards to 3d models.
With version control this is less as an issue. One then needs to have the version of the lib linked to the project in some way. In git this can be done via submodules. Checking out some state of the project will then ensure the global lib is at the state it was when the project was last committed. (renaming global libs is still an issue as it will mean that your lib table is out of sync with the lib at an older state -> so either avoid it or have the lib table somehow liked to the version of the global lib. The later would require a script)
More details: Library management in KiCad version 5
Project local libs have their place but not for generic parts. I would argue it is worse having one version of the SOIC-14 footprint in every project probably in a slightly different state than it is having to deal with setting up global libs on all intended machines. It also will make it harder to track which version of a symbol/footprint pair for a given component is the most recent one.