What you’ve shared here is not itself an error, but rather just Terraform giving some extra information about why it is proposing to destroy this object.
The idea of an object being “tainted” typically represents it being damaged in some way. The most common reason is if there was an error partway through its creation which left the object partially created in a way that the provider doesn’t know how to recover from.
Another way something can become “tainted” is explicitly through the deprecated terraform taint command, but I assume if that were the cause then you would already know you ran that command.
If this object is functioning correctly as far as you are concerned and you don’t want to recreate it then you can use terraform untaint to remove the tainted status without modifying the underlying object. If you do this then you might leave the object in a state that the AWS provider doesn’t understand, but hopefully if you run terraform apply again after untainting the provider will just propose some in-place updates sufficient to make the remote object match your configuration.
Unfortunately I can’t give you a definitive answer about why it is tainted in the first place, because that would have happened on a previous run of Terraform. You mentioned that if you destroy and recreate this object you get back into this same state, and so that means that Terraform ought to be returning an error during the creation of the bucket that explains the cause of the taint status.
Thanks. This makes sense. Yes this occurred when i ran the plan in previous tries. At this point I was able to move forward by cleaning up and re-doing things but its good to know I can untaint if I really need to.