Write down the baseline
mpv documents runtime profiles as option changes. Before applying one during a review, record the small set of values it affects. A familiar profile name does not establish what state will be recovered afterward.
Include a later change in the review
If the profile changes a list such as the filter chain, consider what happens when another adjustment is made before restoration. Restoring a saved value can replace the list; it need not act like removing only the original profile's contribution.
Review profile-restore=copy or profile-restore=copy-equal as documented for your release; the default policy supplies no stored values to restore. Test the chosen policy locally with a harmless owned sample. Compare the final values with the expected baseline. Do not use a live presentation as the first opportunity to discover that a later adjustment was also replaced.
Keep the policy beside the profile
Record whether the profile is launch-only or supported for runtime application, and what later edits are allowed. Recheck nested profiles after changes. This gives the next person a specific apply-and-return contract rather than an undocumented toggle.
Questions answered
Does restore necessarily undo only the last filter addition?
No. Review the documented saved-value behaviour for the affected list.
Should every profile be applied at runtime?
Only when that workflow and its restoration consequences are understood.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.