What’s the significance of the MESH_EXTERNAL/INTERNAL settings in service entry? At first I was under the impression that it signified services with/without a sidecar (or using/not using ambient), but looking at the Kube service conversion logic, this seems to not be the case? Is a better way of thinking of mesh internal "any service that potentially could use Istio mTLS in the future" rather than has a sidecar/in ambient?

I'm interested in this question since I would like to understand whether it makes more sense to construct service entries for VM-esque deployments where inbound istio interception is not active in a way that mirrors K8s (setting location to MESH_INTERNAL and using labels/other mechanisms to configure whether mTLS should be used). This approach seems to be advantageous for handling the partial state where some VMs have a sidecar while others don't compared to what I've currently been doing: creating two service entries, one for internal endpoints and one for external endpoints.