Right, services and modules are the same thing. Note the actual url path inside this quote from App Engine Services as microservices:
In an App Engine project, you can deploy multiple microservices as
separate services, previously known as modules in App Engine.
Namespaces are supported by just a few APIs that services can invoke:
App Engine currently supports namespaces in the following APIs:
They are really just a way to separate/slice (not share) data served by these APIs and can help prevent accidental data leaks across the namespace boundaries. See for example Implementing Multitenancy Using Namespaces. But note that the protection is only as good as the app code is (data will leak if the code is setting the wrong namespace).
Services do not offer data isolation, they can share data regardless of it being in a namespace or not, by appropriately setting the namespace when invoking the respective API. So it's not placing data in a namespace that makes that data shareable across services.
Project bounds apply to both namespaces and services. But it is possible to configure APIs and projects to allow access even across project boundaries (or even from outside Google network - see, for example How do I use Google datastore for my web app which is NOT hosted in google app engine?)
The primary purpose of using services is to obtain code isolation. But it comes with a price - each service has its own instances. Also a bit more difficult: docs and even tools are often a bit behind, many of them assume a single-service GAE app context.
Even though using services to create environments is offered as an alternative in Naming Developer Environments I would stick, as you mention, to using separate projects for that (to also have data isolation).
