Any indices which are still waiting to enter the cold phase will use the updated policy, but any that have already entered the cold phase will use the cold phase defined in the old version of the policy. In your case, if you have an index that rolled over 8 days ago, then you update the min_age for the cold phase in your policy to 7 days, the index will then immediately move to the cold phase.
The reason why this works the way it does is that, if an index is in the middle of a phase, and the phase was updated to use a completely different set of actions, ILM wouldn't know what to do, so if the policy is updated while an index is partway through a phase it will just keep using the same one.
If I'm understanding you correctly, you can see which indices are using the old version by using the Explain API, as shown in the article I linked to - the phase_execution section of the response contains both the version of the policy in use and the actual definition of the phase from the old version of the policy that the index is still using. If the index enters a different phase from the one returned in that response, it will get the new phase from the most recent version of the policy at the time it moves to the new phase.
If you need to change the policy for an index and don't want to wait until the index is through its current phase, then yes, you can remove the policy (although you need to use the Remove policy API rather than just setting index.lifecycle.name to null as the remove policy API will clear the metadata Elasticsearch uses to keep track of where an index is in its policy. (aside: there's an open issue on Github to remove the need for the remove policy API)
Note that when you re-add the policy, the indices will all start from the beginning of the policy, so if you're re-adding a policy to indices that have already rolled over, you probably want to use a policy that does not have rollover.
What I'd recommend for this use case is to create a new policy (for example, my-policy-version-2) and change your index template to use the new policy, rather than updating the existing policy. If you have use cases with slightly different needs, even for the same "set" of indices, don't be afraid to create multiple policies to handle the different or changing requirements.
We are very aware that the current behavior isn't intuitive when it comes to updating existing indices - we would very much like to improve it, but the problem of what to do when an index is partway through a phase when the policy is updated is a difficult one. We're working on it, though!