Note here, when I say, multi-tenant, I think of it as different organizations. There will not be a know it all process in such a situation. That is the initial goal. And yes, we are talking about how to handle situations such as what you suggest above but it may just not be in the initial release.
Per current design, at least in the first release, you will need to call Login once per namespace and not on every request. Once logged in, you will have a jwtToken (tied to that user/namespace combo) that should be used for mutations/queries.
Right. Per current design, one request will have to contain all data pertaining to that tenant. So, segregation will need to be done on the client side. But again, in my mind, multi-tenant means different orgs and they wont need to do this as all data will be presumed to be the same namespace embedded in the jwtToken.
We are still debating on this. However, note this will only help with segregation on the client side. Batching per namespace will still need to be done.
Noted. This seems to be the crux of your concern. We will see about separating the two and will take this under advisement with the team. No promises 
We hear you. Thanks for the comments. We really appreciate such feedback that helps us come up with a feature set that appeals to the majority of use-cases, make a release, gather feedback and iterate over it.
I had raised the same question. This will also solve another related concern about the encryption keys being global and not per namespace. @ibrahim , please opine.
Thanks again. My colleagues will chime in as needed if I missed anything and/or keep me honest.