Just realised I missed a few of your questions from before too, the cluster was formed and reported a status of green when asked for a health report. There are 3 nodes in the cluster and while I can't recall exactly what time I inacted the curl command for the watcher index I can't see anything that relates to that in the logs but they are littered with statments like this
[[.watches/NpKMeiIFQdigvNfVB5R18A]] can not be imported as a dangling index, as index with same name already exists in cluster metadata
The VMs are just to test the upgrade process ahaead of applying it to prod which is on physical tin. They are Gen 1 windows hyperV VMs using checkpoints to allow for quick reset in testing. The run Centos7 and the only real customisation is that the logs go to /logs/elasticsearch/clustername.log and data goes to /data1/elasticserach and /data2/elasticsearch which reports as an issue pre-upgrade but following a test run looked to have no impact and is documented out here Upgrade issue with path.data
In all honesty I haven't really touched anything on the watches on this test cluster. The VMs were built to let me test replacing the nodes in our cluster with new hardware and get a process on paper about a month ago and then as it was setup I've used it to test run the upgrade process too. The test data was 100k employee data sample I found online that I impoarted about 50 times to get the data footprint up. So thinking about it no watches have actually been specificlly configured, it's only what was done automatically that would have come into play.