Deprecation of external references within destroy provisioners

Terraform
1

I have a scenario where I need to run some commands on a particular resource (will refer to this as “target”) when any item in a list (count) of resources is created, updated, or removed. I’m doing this by defining my provisioning blocks within the list of resources so that I can inherit the scope of each element of the resource list. To avoid potential race issues due to destruction, I’ve attempted to generate as many attributes as I can. However, there was no way to work around accessing self.count.index (However, I’d be very surprised for this to be non-computable).

The list resources are also directly dependent on attributes from the “target” resource that I want to run commands on, so unless the graph is being traversed incorrectly we should be able to guarantee that the “target” resource should still be accessible.

However, I get the following deprecation warning. This concerns me because does this mean that the ability to access attributes of other resources or data sources will be impossible in a future version?

Warning: External references from destroy provisioners are deprecated           
                                                                                
  on main.tf line 174, in resource "vsphere_virtual_machine" "fuzzer":          
 174:       host = vsphere_virtual_machine.master.default_ip_address                                                                                            
                                                                                
Destroy-time provisioners and their connection configurations may only          
reference attributes of the related resource, via 'self', 'count.index', or     
'each.key'.                                                                     
                                                                                                                                                                
References to other resources during the destroy phase can cause dependency                                                                                     
cycles and interact poorly with create_before_destroy.

If this is the case, how would I refactor my definitions? As an example of what the definition might look like:

resource "from-some-provider" "target" {
    default_ip_address = <this is exposed>
}

resource "from-same-provider" "items" {
    count = 57005
    name = "item.${count.index}"

    # When resource comes into scope
    provisioner "remote-exec" {
        inline = [
            "echo 1 >| ${self.count.index}"
        ]

        connection {
            type = "ssh"
            host = from-some-provider.target.default_ip_address
        }
    }

    # When resource goes out of scope
    provisioner "remote-exec" {
        when = destroy

        inline = [
            "echo 0 >| ${self.count.index}"
        ]

        connection {
            type = "ssh"
            host = from-some-provider.target.default_ip_address
        }
    }
}

Ideally if I change the count here (which shouldn’t affect “target” at all), the intention is to have a directory of indexes on “target” where each file contains 1 if the resource exists or 0 if the resource does not exist.