There is a functionality with something like that with istio multicluster configuration.

Depending on Your requirements there can be different types of multicluster models.

According to istio documentation:

When configuring a production deployment of Istio, you need to answer a number of questions. Will the mesh be confined to a single cluster or distributed across multiple clusters? Will all the services be located in a single fully connected network, or will gateways be required to connect services across multiple networks? Is there a single control plane, potentially shared across clusters, or are there multiple control planes deployed to ensure high availability (HA)? If there is more than one cluster being deployed, and more specifically in isolated networks, are they going to be connected into a single multicluster service mesh or will they be federated into a multi-mesh deployment?

All of these questions, among others, represent independent dimensions of configuration for an Istio deployment.

1. single or multiple cluster
2. single or multiple network
3. single or multiple control plane
4. single or multiple mesh

All combinations are possible, although some are more common than others and some are clearly not very interesting (for example, multiple mesh in a single cluster).

As for mesh functionality:

Single mesh

The simplest Istio deployment is a single mesh. Within a mesh, service names are unique. For example, only one service can have the name mysvc in the foo namespace. Additionally, workload instances share a common identity since service account names are unique within a namespace, just like service names.

A single mesh can span one or more clusters and one or more networks. Within a mesh, namespaces are used for tenancy.

Multiple meshes

Multiple mesh deployments result from mesh federation.

Multiple meshes afford the following capabilities beyond that of a single mesh:

• Organizational boundaries: lines of business
• Service name or namespace reuse: multiple distinct uses of the default namespace
• Stronger isolation: isolating test workloads from production workloads

You can enable inter-mesh communication with mesh federation. When federating, each mesh can expose a set of services and identities, which all participating meshes can recognize.

To avoid service naming collisions, you can give each mesh a globally unique mesh ID, to ensure that the fully qualified domain name (FQDN) for each service is distinct.

When federating two meshes that do not share the same trust domain, you must federate identity and trust bundles between them. See the section on Multiple Trust Domains for an overview.

So I suggest applying multicluster model to Your needs. The simplest solution is usually the best. Single mesh multicluster does allow for naming locality for Your multicluster environment.

There is also advanced example of multicluster istio with use of Admiral which allows to have custom naming possibilities.

Hope it helps.