I would not try to keep instances identical between clusters in this way (even if it can be compelled to work), for a few reasons. Kibana visualizations, saved searches, dashboards, et. all are tied to the Index Patterns. In pursuing things in this way, you are forced to keep Index Patterns synced and identical between environments, even if it does not make sense to do so. If you ever need to delete and re-create an Index Pattern, it will have a different UUID/Hash/Name, which will force you to re-connect (or worse, recreate) all of the visualizations to the updated Index Pattern ID.
Using Kibana API calls, it is possible to get these Index Pattern names, and upload/update visualization JSON structures as you would with any regular document. This is how the Beats upload Kibana dashboards and create/update Index Patterns. In the event that a change is made on one, it should be possible to check saved/stored documents in Kibana with API calls and simply push/merge them to the other clusters.
If you cannot use cross-cluster replication (which was made available in Elasticsearch 6.6, by the way), then I highly recommend using API calls to update visualizations. If that means storing the JSON dumps in a git repo, doing diffs, and then pushing out changes to other clusters, then so be it. It's a better approach, and one much less likely to cause breakage (which would surely happen with ad-hoc snapshot restores, since closing the index is required).